★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

第50章 レプリケーション進捗の追跡

レプリケーション起点(replication origins)は、ロジカルデコーディングの上に、ロジカルレプリケーションソリューションを実装しやすくすることを意図しています。 以下の2つの良くある問題に対して解決の方策を提供します。

レプリケーション起点は、名前とIDから構成されます。 システム中で起点を参照する際に使われる名前は、任意のtextです。 その名前は、たとえばレプリケーションソリューションの名前を接頭辞にすることにより、別々のレプリケーションソリューションによって作成されたレプリケーション起点が衝突することがないように使われるべきです。 IDは、空間効率が重要な場合に、長い名前を格納することを避けたいときにのみ使用します。 システム間で共有すべきものではありません。

レプリケーション起点はpg_replication_origin_create()で作成し、pg_replication_origin_drop()で削除し、pg_replication_originシステムカタログを使って参照します。

レプリケーションソリューションを構築する際に無視できない問題は、どうやってリプレイの進捗を安全に追跡するか、ということです。 (訳注: ログを)適用するプロセス、あるいはシステム全体が死んだ時に、どこまでデータのレプリケーションが成功したかを見つけることができなければなりません。 トランザクションのリプレイの度にテーブルの行を更新するような素朴なソリューションは、実行時のオーバーヘッドとデータベースの肥大化問題を起こします。

レプリケーション起点のインフラを使用することにより、あるセッションに対してリモートノードからリプレイしていることの目印を付けることができます。(pg_replication_origin_session_setup()を使います) また、 pg_replication_origin_xact_setup()を使ってすべてのソーストランザクションに対してトランザクション単位でLSNとタイムスタンプを記録するように設定することができます。 終了後は、クラッシュに対して安全な方法で、レプリケーションの進捗は永続的に記録されます。 すべてのレプリケーション起点のリプレイの進捗は、pg_replication_origin_statusビューで参照できます。 たとえばレプリケーションの再開の際などには、個々の起点の進捗を、pg_replication_origin_progress()で参照できます。 現在のセッションに起点が設定されている場合は、pg_replication_origin_session_progress()を使用します。

厳密に一つのシステムから別の一つのシステムにレプリケーションする以上のより複雑なレプリケーションのトポロジでは、リプレイされた行を再びレプリケーションするのを避けるのが難しいという別な問題が発生するかもしれません。 これにより、レプリケーションの巡回と、非効率性の両方が発生するかもしれません。 レプリケーション起点には、この問題を認識し、避けるためのオプションの機構があります。 前段で言及した関数を使うと、出力プラグインコールバック(49.6参照)に渡されるすべての更新とトランザクションに、セッションを生成しているレプリケーション起点がタグ付けされます。 これにより、出力プラグインの中でそれらの扱いを分けることができます。たとえばローカルに起因する行以外はすべて無視するような場合です。 また追加で、ソースに基づくロジカルデコーディングの変更ストリームをフィルターするためにfilter_by_origin_cbコールバックを使うことができます。 これは柔軟ではありませんが、アウトプットプラグインを通してフィルタリングするのはずっと効率的です。