Lakebaseへのデータ複製

このガイドでは、外部PostgresデータベースからLakebaseに論理的レプリケーションを使ってデータを複製する方法を紹介しています。 Lakebaseはサブスクライバーとして機能し、元のデータベースに接続し、既存データをコピーし、切り替えを行うまで継続的な変更を反映します。 これを使って、Amazon Aurora PostgreSQLやAmazon RDS for PostgreSQLなどの他のPostgresプロバイダーからデータベースを移行したり、セルフマネージドのPostgresサーバーからLakebaseへ移行できます。

前提 条件

  • Lakebaseがアクセス可能なパブリックエンドポイントを持つSource Postgresデータベース。
  • ソースデータベースのスーパーユーザーアクセス、またはマネージド Postgres サービスの管理者アカウント。 wal_levelの設定、REPLICATION属性でのロールの作成、公開の作成はすべてこのレベルのアクセスを必要とします。
  • ターゲットデータベース用のLakebaseプロジェクトです。
  • サブスクリプションを作成するための Lakebase Postgres ロール: databricks_superuser ロールのメンバー、または pg_create_subscription 事前定義ロールが付与されたロール。 Postgres ロールの作成を参照してください。

Lakebaseでは論理複製がサポートされています。 プロジェクトごとにオンにする手順はありません。 加入者にとって、Lakebaseはwal_levelの変更を必要としません。 wal_level = logicalが必要なのはソースパブリッシャーだけです。

ソースデータベースを準備する

元のPostgresデータベースで、先行書き込みログを logical に設定し、レプリケーション用の空き容量があることを確認してください。 以下の例はセルフマネージ型Postgresのものです。 管理されているPostgresプロバイダーは、さまざまな設定を使うかもしれません:

ALTER SYSTEM SET wal_level = logical;
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_replication_slots = 10;

wal_levelの変更を有効にするためにソースデータベースを再起動してください。 マネージドサービスでは、プロバイダーのパラメータグループやフラグを使って wal_level を logicalに設定します。 例えば、Amazon Aurora PostgreSQLでは、DBクラスタパラメータグループで rds.logical_replication を 1 に設定し、クラスタを再起動します。 Amazon RDSのPostgreSQLでは、DBパラメータグループに同じパラメータを設定し、インスタンスを再起動してください。

レプリケーション用のロールを作成し、レプリケーション対象のテーブルへの読み取り権限を付与します:

CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD '<password>';
GRANT USAGE ON SCHEMA public TO replication_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO replication_user;

この CREATE ROLE ステートメントは、自己管理型のPostgresサーバー上で書かれた通りに動作します。 一部のマネージドPostgresプロバイダーは REPLICATION 属性を直接許可せず、プロバイダー固有の役割を通じてレプリケーションアクセスを許可しています。 ソースがマネージドサービス上で動作している場合は、プロバイダーのドキュメントに従ってロールにレプリケーションアクセスを与え、その後の手順で replication_user の代わりにその役割を使いましょう。 例えば、Amazon Aurora PostgreSQL や Amazon RDS for PostgreSQL では、WITH REPLICATION を付けずにロールを作成し、GRANT rds_replication TO replication_user を実行します。

複製するテーブルのパブリケーションを作成します。 各テーブルには PRIMARY KEY またはレプリカ ID が設定されている必要があります。 Postgresのドキュメントにある レプリカアイデンティティ についてご参照ください。

CREATE PUBLICATION my_publication FOR TABLE orders, customers;

Lakebaseが源に到達できるようにしてください

サブスクライバーとして、Lakebaseはあなたのソースデータベースに発信接続を行います。 このアウトバウンド接続はアカウントのネットワークポリシーによって規定されており、そのネットワークポリシーが、サーバーレスワークロードが到達できるインターネット上の宛先を制御します。 Lakebaseのプロジェクト設定やデータベース内のロールによって制御されるわけではありません。

変更が必要かどうかは、あなたのアカウントがネットワークポリシーを適用しているかどうかによります。

  • アクティブネットワークポリシーなし:Lakebaseは到達可能なパブリックエンドポイントを持つ任意のパブリッシャーに到達可能です。 変更する必要はない。
  • アクティブネットワークポリシー:アカウントネットワークポリシーで、ソースデータベースのホストを許可されたインターネット宛先に追加します。 ネットワーク ポリシーの管理を参照してください。 ホストが許可されていない場合、登録時にそのサブスクリプションは拒否されます。 トラブルシューティングに関するページを参照します。

加入者接続にはPrivate Linkはサポートされていません。 ソースデータベースは公開エンドポイントを通じてアクセス可能でなければなりません。

ターゲットテーブルを作成する

論理レプリケーションはスキーマではなく、データをコピーします。 レプリケーションを始める前に、ターゲットのLakebaseデータベースでソースと同じ名前とカラムのテーブルを作成してください。 手動で作成することもできますし、ソースからスキーマをダンプしてLakebaseに読み込むこともできます。 「 スキーマのみをダンプする」を参照してください。

ターゲットテーブルは空に作成します。 ターゲットテーブルにすでに行が含まれている場合、初期のテーブルコピーは重複キーや制約違反で失敗します。

サブスクリプションを作成する

ターゲットのLakebaseデータベースにサブスクリプションを作成できるロールとして接続してください( 事前条件を参照)、その後、ソースパブリッシャーに接続するサブスクリプションを作成します。

CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=<source-host> port=5432 dbname=<source-db> user=replication_user password=<password> sslmode=verify-full sslrootcert=system'
PUBLICATION my_publication;

サブスクリプションを作成すると、元のパブリッシャー上でレプリケーションスロットが開始され、既存の行がコピーされ、その後、進行中の変更がストリーミングされます。

Warning

レプリケーションスロットは、Lakebaseが変更を受信したことを確認するまで、ソースデータベースが書き込み先行ログ(WAL)を保持します。 サブスクリプションが無効化、切断、または正常に動作していないなどで変更の消費を停止すると、WALはソース上で無限に蓄積されます。 本番環境のソースでは、これがソースのストレージを埋め尽くし、障害を引き起こすことがあります。

レプリケーション実行中は、スロットがソース側にどれだけのWALを保持しているかを監視してください:

SELECT slot_name, active,
       pg_catalog.pg_size_pretty(pg_catalog.pg_wal_lsn_diff(pg_catalog.pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_catalog.pg_replication_slots;

セルフマネージドソースのリスクを抑えるには、max_slot_wal_keep_size を設定して、スロットが保持できる WAL の量を制限してください。 スロットが上限を超えた場合、Postgresはそのスロットを無効にし、サブスクリプションを再作成しなければなりません。 移行が完了したらすぐにサブスクリプションを解約してください。 レプリケーションスロットとストレージを参照してください。

Note

Lakebaseがサブスクライブすると、お客様のソースデータベースに外向きに接続し、レプリケーションロールの認証情報をそのデータベースに送信します。 sslmode=verify-full sslrootcert=systemは接続を暗号化し、送信元の身元を検証することで、中継された認証情報を中間者攻撃から守ります。 これは、ソースが公に信頼されている認証局を使っている場合に機能します。 弱い sslmode=require は暗号化しますが、送信元を検証しません。 プライベート認証機関を使用するソースの検証はサポートされていません。

レプリケーションを検証

ターゲットのLakebaseデータベースで、既存の行が取り込まれていることを確認します:

SELECT COUNT(*) FROM orders;

ソースに行を挿入または更新し、再度ターゲットをクエリします。 変化は数秒以内にLakebaseに現れます。

監視して切り替える

初期コピーと進行中のラグを追跡してください:

SELECT subname, received_lsn, latest_end_lsn, last_msg_receipt_time
FROM pg_catalog.pg_stat_subscription;

初期コピーが完了したか確認するために、サブスクライバーの Monitor replication でテーブルごとの同期状態クエリを実行し、すべてのテーブルが Ready (fully live) と表示されるまで待ちます。

ターゲットが追いついたら、ソースの書き込みを停止し、ターゲットが完全に最新であることを確認し、アプリケーションをLakebaseの接続詳細に切り替えます。

論理レプリケーションはシーケンス値やIDENTITYカウンターをコピーしません。 Lakebaseで書き込みを再開する前に、各ターゲットシーケンスを複製データに合わせてリセットしてください。そうしないと、SERIAL または IDENTITY 列への新しい挿入で重複した主キーが生成されることがあります。

SELECT pg_catalog.setval(pg_catalog.pg_get_serial_sequence('orders', 'id'), (SELECT MAX(id) FROM orders));

アプリケーションがLakebaseに対して動作したら、ソースからのレプリケートをやめるためにサブスクリプションを削除してください。 送信元に到達可能な場合、サブスクリプションを解除するとレプリケーションスロットも削除されます。 「サブスクリプションまたは発行の削除」を参照してください。

監視とクリーンアップについては、論理複製の管理と監視を参照してください。

次のステップ

  • レプリケーション管理:サブスクリプションの監視、スロット管理、トラブルシューティングを行います。 「 論理複製の管理と監視」を参照してください。
  • Lakebaseからのストリーム:Lakebaseの変更を外部Postgres購読者に公開します。 Lakebase からデータを複製するを参照してください。
  • 方法を比較する:Lakebaseへのデータの出入りに適切な方法を選択してください。 「Lakebase へのデータの出入り」を参照してください。
  • 最終更新: