論理レプリケーションの管理と監視

このページでは、Lakebaseにおける論理レプリケーションの監視方法、レプリケーションがスケール・トゥ・ゼロおよびブランチとどのように相互作用するか、そして一般的な問題の解決方法について説明しています。セットアップについては、「Lakebaseへのデータレプリケート」および「Lakebaseからのデータをレプリケートする」をご覧ください。

画面を複製

任意のPostgresロールはこのページのレプリケーションカタログをクエリできますが、2つの例外があります。 pg_subscriptionのsubconninfo列には接続パスワードが含まれていて制限されているため、SELECT *を使うのではなく特定の列を選択してください。 pg_stat_replicationでは、ほとんどの列は、役割に pg_read_all_stats がある場合を除き非表示にされており、databricks_superuser のメンバーはこれを持っています。

購読者で、そのサブスクリプションが存在し有効であることを確認してください:

SELECT subname, subenabled FROM pg_catalog.pg_subscription;

出版社の画面で、出版物の存在を確認してください:

SELECT pubname FROM pg_catalog.pg_publication;

サブスクライバーのテーブルごとの同期状況を確認してください。すべてのテーブルが Ready (fully live) と表示されたら、初回コピーが完了し、サブスクリプションはストリーミング配信されます:

SELECT
    srrelid::regclass AS table_name,
    CASE srsubstate
        WHEN 'i' THEN 'Initializing'
        WHEN 'd' THEN 'Data copying (in progress)'
        WHEN 's' THEN 'Synchronized (catching up)'
        WHEN 'r' THEN 'Ready (fully live)'
    END AS sync_status
FROM pg_catalog.pg_subscription_rel;

サブスクリプション状況とラグを確認してください:

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

パブリッシャーとサブスクライバーの行数を比較して、テーブルが同期しているか確認してください:

SELECT COUNT(*) FROM public.playing_with_lakebase;

パブリッシャーでは、レプリケーションスロットとそれぞれがどこまで進んでいるかを一覧表示します:

SELECT slot_name, slot_type, active, restart_lsn
FROM pg_catalog.pg_replication_slots;

Lakebaseでは、結果には内部の物理スロット wal_proposer_slot と wal_retention_slot も含まれます。 Lakebaseはこれらのスロットを管理しており、論理複製の一部ではありません。

論理複製とゼロへのスケール

アクティブなサブスクライバーがあるLakebaseコンピュートは0までスケーリングされず、コンピュート使用量が増加する可能性があります。

アクティブ購読者の確認:

SELECT *
FROM pg_catalog.pg_stat_replication
WHERE application_name <> 'walproposer';

レプリケーションスロットとストレージ

レプリケーションスロットは、サブスクライバーが変更を受信したことを確認するまで、パブリッシャーが書き込み先行ログ（WAL）を保持します。例えば、サブスクライバーが無効化、切断、障害が発生している、遅れなどで変更の消費を停止すると、WALはパブリッシャーに蓄積されます。これが論理複製における深刻な問題の最も一般的な原因です:

パブリッシャーはストレージが不足することもあります。 保持されたWALはパブリッシャーのストレージが満杯になるまで成長し、それがデータベースの書き込み受付を停止させ、障害を引き起こすことがあります。
スロットを落としてもすぐにストレージが解放されるわけではありません。 Postgresは、後のチェックポイントでWALセグメントを再利用する場合にのみ、保持されているWALを削除します。もしパブリッシャーがすでにストレージを使い果たしているなら、その再利用は完了しないかもしれません。
このリスクは外部出版社にも当てはまります。 Lakebaseが外部データベースにサブスクライブすると、サブスクリプションが変更の消費を停止すれば、WALはその外部ソースに蓄積されます。

保持されたWALの監視

パブリッシャーで、各論理スロットがどれだけのWALを保持しているか、そしてアクティブかどうかを確認してください:

SELECT slot_name, active, wal_status,
       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
WHERE slot_type = 'logical';

レプリケーションがアクティブな間は定期的にこのクエリを実行してください。 retained_walが増え続けるとき、またはactiveがfalseであるときを調べましょう。 wal_statusのextendedは、そのスロットが通常パブリッシャーが保持する以上のWALを保持していることを意味します。 lostまたはwal_statusのunreservedは、スロットがmax_slot_wal_keep_sizeを超え、必要なWALを失いつつあるか、すでに失っているため、サブスクリプションを再作成する必要があることを意味します。

WALの蓄積から回復

Monitor retained WALのクエリでWALを保持しているスロットを見つけてください。
サブスクライバーが回復できる場合は、ネットワークの問題、無効化された購読、または適用の失敗などの原因を修正して、サブスクライバーが追いつき、スロットが進みます。
もしサブスクリプションが不要なら、加入者から削除してください。加入者に連絡が取れない場合は、その枠を直接パブリッシャーにドロップしてください。スロットは、ドロップする前に非アクティブである必要があります:
```
SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');
```
パブリッシャーが保持されたWALを再循環するのを待ちましょう。ストレージがほぼ尽きかけているセルフマネージド発行元では、まずストレージを追加してリサイクルを完了させましょう。

Lakebase の非稼働スロットの自動削除

Lakebaseがパブリッシャーの場合、約40時間非アクティブだったレプリケーションスロットを自動的に削除し、スロットが無期限にWALを保持しないようにします。スロットは、加入者が変更の消費を停止し、スロットの進行が止まると非アクティブになります。これは、加入者が無効化されたり利用不可になったり、加入者が長いレプリケーション遅延で構成されている場合に発生します。

スロットが削除されないようにするには、そのサブスクライバーが接続を維持し、変更を継続的に受信し続けるようにしてください。サブスクライバーが設定可能なレプリケーション遅延や頻度を使用している場合は、40時間未満に抑えてください。そうすればスロットが進み続けます。スロットが削除されてまだ必要な場合は、サブスクライバーでサブスクリプションを再作成してください。

外部パブリッシャーは非アクティブな枠を自動的に削除しません。セルフマネージドパブリッシャーでは、スロットが保持できるWALの上限に max_slot_wal_keep_size を設定しましょう。スロットが制限を超えると、Postgresはそれを無効にし、サブスクリプションを再作成しなければなりません。

ブランチの復元はレプリケーションスロットを解除します

ブランチを復元すると、そのブランチ上のすべてのレプリケーションスロットが削除されます。ブランチの復元後にパブリケーションとサブスクリプションを再作成してください。

子ブランチはサブスクリプションを継承しません

親ブランチで定義されたサブスクリプションは、その子ブランチには複製されません。 Lakebaseは子ブランチの計算開始前に子ブランチからそれらを削除するため、2つのコンピュートが同じサブスクリプションを複製しません。これは子ブランチの作成、リセット、復元時に適用されます。レプリケーションが必要なら子ブランチでサブスクリプションを再作成してください。

データベースを削除すると、そのサブスクリプションが削除されます

DROP DATABASEコマンドや操作に応じてデータベースをドロップする前に、Lakebaseはそのデータベースで定義された論理レプリケーションサブスクリプションをすべて削除します。

レプリケーションの役割

専用のレプリケーション役割は REPLICATION 属性を持たなければなりません。 Lakebase App、Azure Databricks CLI、またはREST APIで作成されたロールは、databricks_superuserのメンバーかどうかに関わらずこの属性を持ちます。 SQLで作成されたロールは自動的に REPLICATION 属性を受け取りません。 SQLで作成する場合は、属性を含めます。たとえば CREATE ROLE replication_user WITH LOGIN REPLICATION PASSWORD '<password>';。既存のロールに追加するには、ALTER ROLE <role_name> REPLICATION; を実行します。どちらのステートメントも、プロジェクトオーナーの役割など、 CREATEROLE および REPLICATION 属性を持つ役割を必要とします。

役割の権限を確認する:

SELECT rolname, rolreplication
FROM pg_catalog.pg_roles
WHERE rolname = '<role_name>';

デコーダープラグイン

Lakebaseは2つの論理デコード出力プラグインをサポートしています:

pgoutput:組み込みのPostgres論理レプリケーションプラグインであり、デフォルトでもあります。標準的なPostgres 間のレプリケーションに使ってください。
wal2json: 変更データをJSONで消費するシステムでは、WALの変更をJSONとして出力します。

Publisherの設定

Lakebaseでは、 max_wal_senders と max_replication_slots の両方が 10に設定されています:

max_wal_senders = 10
max_replication_slots = 10

max_wal_senders は、加入者に変更をストリーミングする同時実行の WAL 送信プロセスに上限を設け、max_replication_slots は、加入者の進捗を追跡するレプリケーションスロットに上限を設けます。購読者ごとにそれぞれ1つずつ見込んでください。異なる値をリクエストするにはDatabricksにお問い合わせください。

専用のレプリケーションスロットを作成する

一部のデータサービスでは、事前に作成しておくレプリケーションスロットが必要です。標準のPostgres関数で、次のデコーダープラグイン名を指定して1つ作成します。

SELECT pg_catalog.pg_create_logical_replication_slot('my_replication_slot', 'pgoutput');

購読または発行の削除

不要になったら、購読者からサブスクリプションを削除しましょう。パブリッシャーに到達可能な場合、サブスクリプションを解除するとパブリッシャーから切断され、パブリッシャー上のレプリケーションスロットが削除されます。複製されたデータはサブスクライバーデータベースに残ります。

DROP SUBSCRIPTION my_subscription;

パブリッシャーに連絡が取れない場合は、リモートスロットを外すために接続できないため、DROP SUBSCRIPTION は完了しません。まずスロットを解除し、その後サブスクリプションを削除してください:

ALTER SUBSCRIPTION my_subscription DISABLE;
ALTER SUBSCRIPTION my_subscription SET (slot_name = NONE);
DROP SUBSCRIPTION my_subscription;

この場合、レプリケーションスロットはパブリッシャーに残り、WALを保持し続けます。パブリッシャー上でそれを削除してWALをリリースする:

SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');

出版社に出版物をドロップする:

DROP PUBLICATION my_publication;

Troubleshooting

症状:	原因と解決策
サブスクリプションに接続できません。	パブリッシャーに到達可能であること、および接続文字列、role、password が正しいことを確認してください。 Lakebaseがサブスクライバーの場合、パブリッシャーのエンドポイントがアカウントネットワークポリシーの許可リストに載っているか確認してください。 Lakebase にデータを複製するをご覧ください。
別のLakebaseデータベースへのサブスクリプションがハングし、接続できません。	同じリージョン内のLakebaseデータベース間のレプリケーションはサポートされていません。ソースとターゲットは異なるリージョンに存在しなければなりません。制限事項を参照してください。
`CREATE SUBSCRIPTION` は `restricted by Account Network Policies`で失敗します。	あなたのアカウントはネットワークポリシーを適用しており、パブリッシャーホストは許可されたインターネット送信先に含まれていません。ホストをアカウントのネットワークポリシーに追加してください。 Lakebase にデータを複製するをご覧ください。
ストレージは増加し、解放されません。	レプリケーションスロットは、サブスクライバーが変更を消費していないためWALを保持しています。解決されないままだと、パブリッシャーはストレージを使い果たすことがあります。保留されたWALを確認し、サブスクライバーを再接続するかスロットを削除してください。ストレージは、パブリッシャーがWALを再循環した後にのみリリースされます。レプリケーションスロットとストレージを参照してください。
行はサブスクライバーに届きません。	ターゲットテーブルが名前と列が一致していること、そしてパブリケーションに期待するテーブルが含まれていることを確認しましょう。

次のステップ

Lakebaseへの複製: 既存のPostgresデータベースをLakebaseに複製します。 Lakebase にデータを複製するをご覧ください。
Lakebaseからのストリーミング: 外部のPostgresサブスクライバーに変更を公開。 Lakebase からデータを複製するを参照してください。
機能を理解する:論理レプリケーションとは何か、いつ使うべきかを確認しましょう。論理レプリケーションを参照してください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-10-15