PostgreSQL データベースからデータをストリーミングする

このセクションには、次に関する情報が含まれています。

  • Datastream が移行元 PostgreSQL データベースから pull されているデータを処理する方法の動作
  • Datastream でサポートされている PostgreSQL データベースのバージョン
  • データが移行先にストリーミングできるように移行元 PostgreSQL データベースを設定する方法の概要
  • PostgreSQL データベースを移行元として使用する場合の既知の制限事項

動作

移行元の PostgreSQL データベースは論理デコーディング機能に依存しています。論理デコーディングでは、データベースにコミットされたすべての変更が公開され、出力プラグインを使用してこれらの変更をユーザー フレンドリーな形式で使用、処理できます。Datastream は、PostgreSQL 10 以降の標準の PostgreSQL 論理デコーディング プラグインである pgoutput プラグインを使用します。

  • 特定の PostgreSQL 移行元からのすべてのスキーマまたは特定のスキーマ、およびスキーマや特定のテーブルのすべてのテーブルを選択できます。
  • 履歴データはすべて複製されます。
  • 指定したデータベースとテーブルからの挿入、更新、削除など、すべてのデータ操作言語（DML）の変更が複製されます。
  • commit された変更のみが複製されます。
  • テーブルに REPLICA IDENTITY を定義すると、Datastream は指定された列を主キーとして扱います。
  • Datastream は、ハートビート メッセージをソース データベースに定期的に送信します。その結果、論理デコーディング メッセージ イベント（op:"m"）が WAL ファイルに直接挿入されます。これらのメッセージは、ソースの可用性を確保し、鮮度を計算するために Datastream で必要になります。他のレプリケーション設定が同じソース データベースから読み取る場合は、この点を考慮することをおすすめします。

バージョン

Datastream は、PostgreSQL バージョン 10 以降をサポートしています。

Datastream は、次の種類の PostgreSQL データベースをサポートしています。

  • セルフホストの PostgreSQL
  • Cloud SQL for PostgreSQL
  • AlloyDB for PostgreSQL
  • AlloyDB Omni
  • Amazon RDS for PostgreSQL
  • Amazon Aurora PostgreSQL

ベスト プラクティス

このセクションでは、Datastream で使用する PostgreSQL ソースを構成する際の推奨されるベスト プラクティスについて説明します。

複数のストリームを使用してヘッドオブライン ブロッキングを防ぐ

PostgreSQL ソースの場合、Datastream はストリーム全体に対して単一の論理レプリケーション スロットを使用します。1 つの大容量テーブルに対する大規模なトランザクションまたは複数の更新により、同じストリーム内の他のすべてのテーブルのデータ レプリケーションが遅延する可能性があります。

ヘッドオブライン ブロッキングを防ぐには、テーブルのセットごとに個別のストリームを作成します。たとえば、大容量テーブル用に 1 つのストリームを作成し、小容量テーブル用に別のストリームを作成できます。これにより、高チャーン テーブルが分離され、他のテーブルのレプリケーションが遅延するのを防ぐことができます。

推奨事項: 書き込み（INSERT/UPDATE/DELETE）率が異常に高いテーブルを特定し、個別のレプリケーション スロットを使用して、専用の Datastream ストリームに配置します。

長時間実行されるトランザクションを回避する

長時間実行されるトランザクションは、Write-Ahead Log（WAL）の蓄積につながる可能性があります。WAL はシーケンシャルであるため、他のトランザクションが消費されている場合でも、長いトランザクションが完了するまで PostgreSQL は WAL をフラッシュできません。これにより、レプリケーション スロットのサイズが増加し、論理デコードが遅くなる可能性があります。これは、現在のトランザクションと重複する長時間実行トランザクションの変更を繰り返しデコードする必要があるためです。

推奨事項: ソース データベースで、長時間実行されるトランザクションを回避するように statement_timeout パラメータと idle_in_transaction_session_timeout パラメータを構成します。詳細については、PostgreSQL のドキュメントをご覧ください。

パブリケーションの作成時にテーブル フィルタリングを使用する

少数のテーブルからのみ変更を複製する場合は、それらのテーブルのみを含む PUBLICATION を作成してください。パブリケーションが特定のテーブルにスコープ設定されている場合、PostgreSQL はレプリケーション スロット内のこれらのテーブルの変更のみを効率的に保持します。これにより、レプリケーション スロットのサイズが縮小され、論理デコードのパフォーマンスが向上します。

レプリケーション スロットをプロアクティブに管理する

Datastream は PostgreSQL プライマリ インスタンスの論理レプリケーション スロットを使用します。これにより、Datastream が WAL ファイルの処理を確認するまで、WAL ファイルが保持されます。ストリームが失敗、一時停止、またはレプリケーション スロットを削除せずに削除された場合、PostgreSQL は WAL ファイルを無期限に保持し続けます。これにより、データベース サーバーのディスクが満杯になり、本番環境が停止する可能性があります。

推奨事項: 効率的なアラートを設定し、移行元の PostgreSQL サーバーで WAL ディスク使用量をモニタリングします。

レプリカ ID を正しく構成する

REPLICA IDENTITY 設定は、UPDATE イベントと DELETE イベントの WAL に書き込むデータを PostgreSQL に指示します。これにより、Datastream はどの行が変更されたかを特定できます。

BigQuery を宛先として使用する場合は、REPLICA IDENTITY を FULL に設定しないでください。Datastream は、ログに記録された列を BigQuery MERGE オペレーションの論理キーとして使用します。REPLICA IDENTITY が FULL に設定され、テーブルに 17 個以上の列がある場合、MERGE オペレーションの主キーに対する BigQuery の 16 列の上限を超え、ストリームが中断されます。

推奨事項（優先順位順）:

  1. 最適: 主キーを使用します。REPLICA IDENTITY DEFAULT のデフォルト設定では、既存の主キーが自動的かつ効率的に使用されます。
  2. 良好: プライマリ キーが存在しない場合は、UNIQUE NOT NULL インデックスを作成して REPLICA IDENTITY USING INDEX INDEX_NAME を設定します。
  3. 推奨度が最も低い: 一意の識別子がないテーブルでのみ REPLICA IDENTITY FULL 設定を使用します。BigQuery に複製する場合は、パフォーマンスへの影響、16 列の制限、主キーでサポートされているデータ型の制限に注意してください。

既知の制限事項

PostgreSQL データベースを移行元として Datastream を使用する場合の既知の制限事項は次のとおりです。

  • ストリームは 10,000 テーブルに制限されています。
  • 次の条件が満たされない限り、5 億行を超えるテーブルはバックフィルできません。
    1. テーブルには一意の B-tree インデックスがある。
    2. インデックスには、DOUBLE、FLOAT、MONEY、REAL、JSON、JSONB、BYTEA、TXID、XML 型、複合データ型、ジオメトリ データ型の列は含まれません。
    3. インデックスのどの列も null 値を許容できません。
    4. インデックスのすべての列が昇順、またはインデックスのすべての列が降順になります。
    5. インデックスのすべての列がストリームに含まれる。
  • 主キーのないテーブルには REPLICA IDENTITY が必要です。それ以外の場合、INSERT イベントのみが移行先に複製されます。
  • 主キーがあるテーブルでは、REPLICA IDENTITY を FULL または NOTHING に設定できません。DEFAULT に設定する必要があります。
  • PostgreSQL はリードレプリカの論理デコードをサポートしていないため、Datastream はリードレプリカ インスタンスから複製できません。
  • 移行元のスキーマに対するすべての変更を自動的に検出できない場合があります。その場合、データが破損する可能性があります。次のスキーマの変更により、データが破損したり、イベントのダウンストリームが処理されなかったりする可能性があります。
    • 列をドロップする。
    • テーブルの中央に列を追加する。
    • 列のデータ型を変更する。
    • 列を並べ替える。
    • テーブルをドロップする（新しいデータを追加して同じテーブルを再作成する場合に関連）。
  • Datastream は、geometric データ型の列をサポートしていません。
  • Datastream は、range データ型の列をサポートしていません。
  • Datastream は、サポートされていないデータ型の配列、ユーザー定義のデータ型（ENUM など）の配列、または DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE データ型の配列をサポートしていません。このような列は無視されます。
  • Datastream は、テーブルのレプリカ ID の一部である列に TOAST 値を含む行の UPDATE イベントの複製をサポートしていません。このようなイベントは破棄されます。
  • Datastream は、2,950 個を超えるネストされたオブジェクトを含む JSON または JSONB 値を含む行の複製をサポートしていません。このような JSON 値や JSONB 値を含むイベントは、移行先データベースに複製されません。
  • Datastream は、NUMERIC (precision, scale) 列に NaN 値を含む行の複製をサポートしていません。このような列の値は NULL 値に置き換えられます。
  • Datastream は、hstore データ型の列の複製をサポートしていません。このような列の値は NULL 値に置き換えられます。
  • Datastream は、SQL_ASCII でエンコードされた移行元データベースからの非 ASCII レコードの複製をサポートしていません。このようなレコードは破棄されます。
  • Datastream は、行レベルのセキュリティ（RLS）ポリシーが定義されているテーブルの複製をサポートしていません。 この制限を回避する方法については、PostgreSQL の移行元の動作と制限事項をご覧ください。
  • Datastream は、生成された列に対する変更をキャプチャしません。
  • データベースで PostgreSQL のメジャー バージョン アップグレードが実行されると、Datastream が動作を停止したり、新しいイベントをキャプチャしなくなったりする可能性があります。アップグレードの前にレプリケーション スロットを削除し、データベースをアップグレードしてから、レプリケーション スロットを再作成することをおすすめします。ストリームが失敗した場合は、新しいレプリケーション スロット名を指定してストリームを復元し、データの整合性が必要な場合はバックフィルを実行します。

次のステップ