3.2.4. PostgreSQL コネクターの仕組み

3.2.4.1. スナップショット

ほとんどの PostgreSQL サーバーは、WAL セグメントにデータベースの完全な履歴を保持しないように設定されます。そのため、PostgreSQL コネクターは WAL を読み取るだけでデータベースの履歴全体を表示できません。そのため、デフォルトでは、初回起動時にコネクターがデータベースの初期 一貫性のあるスナップショット を実行します。各スナップショットは以下の手順で構成されます（ビルトインスナップショットモードを使用している場合 、 カスタムスナップショットモードはこれをオーバーライドできます）。

  1. SERIALIZABLE、READ ONLY、DEFERRABLE 分離レベルでトランザクションを開始し、 このトランザクション内のすべての後続読み取りがデータの単一のバージョンに対して実行されるようにします。その後のデータの変更や INSERT UPDATE、他のクライアントによる DELETE 操作はこのトランザクションからは認識されません。
  2. 各監視されるテーブルの ACCESS SHARE MODE ロックを取得して、スナップショットの発生中に構成の変更が発生しないようにします。このロックはテーブル UPDATES DELETES を妨げず INSERTS、操作中に実行できないことに注意してください。この手順は、エクスポートされたスナップショットモードを使用してロックなしのスナップショットを許可する場合に省略 されます。
  3. サーバーのトランザクションログの現在の位置を取得します。
  4. データベーステーブルおよびスキーマをすべてスキャンし、各行の READ イベントを生成し、そのイベントを適切なテーブル固有の Kafka トピックに書き込みます。
  5. トランザクションをコミットします。
  6. コネクターオフセットでスナップショットが正常に完了したことを記録します。

コネクターが失敗する場合や、ステップ 1 の開始後、ステップ 6 の完了前にコネクターがリバランスされる場合、コネクターを再起動すると、新しいスナップショットが開始されます。コネクターが最初のスナップショットを完了したら、PostgreSQL コネクターはステップ 3 中に、位置読み取りからストリーミングを継続し、更新をミスしないようにします。コネクターが何らかの理由で再度停止した場合、再起動すると、以前停止した場所から変更のストリーミングが続行されます。

2 つ目のスナップショットモードを使用すると、コネクター は常に スナップショットを実行できます。この動作は、起動時に 常に スナップショットを実行するようにコネクターに指示し、スナップショットが完了したら、上記のシーケンスで手順 3 から変更をストリーミングを継続します。このモードは、一部の WAL セグメントが削除され、利用できなくなったことを把握する場合や、新規プライマリーのプロモート後にクラスター障害が発生した場合に使用できます。これにより、新しいプライマリーの昇格後に行った可能性のある変更がコネクターによって失われないようにし、新しいプライマリーでコネクターが再起動する前に発生する可能性があります。

3 つ目のスナップショットモードは、コネクターがスナップショットを実行し ない ように指示します。新しいコネクターを設定すると、以前保存されたオフセットからの変更のストリーミングが継続される場合、PostgreSQL の論理レプリケーションスロットが最初に作成されたときに開始します。このモードは、対象のすべてのデータが WAL に反映されている場合にのみ役に立つことに注意してください。

4 番目のスナップショットモード は、初期 にデータベーススナップショットを実行してから、他の変更をストリーミングする前に停止します。コネクターが起動していても、停止前にスナップショットが完了しなかった場合、コネクターはスナップショットプロセスを再起動して、スナップショットが完了すると停止します。

エクスポートさ れる 5 番目のスナップショットモードは、レプリケーションスロットが作成された時点に基づいてデータベースのスナップショットを実行します。このモードでは、ロックなしの方法でスナップショットを実行することが非常に優れています。