Aurora PostgreSQL 互換のソース DB クラスターにおける論理レプリケーションの問題をトラブルシューティングする方法を教えてください。

所要時間2分

Amazon Aurora PostgreSQL 互換エディションのソースデータベース (DB) クラスターにおける論理レプリケーションの問題をトラブルシューティングしたいと考えています。

解決策

レプリケーションパラメータを設定する

論理レプリケーションの問題をトラブルシューティングする前に、DB クラスターパラメータグループの次のパラメータを設定します。

rds.logical_replication の値を 1 に設定して、DB クラスターで論理レプリケーションを有効にします。
max_replication_slots には、想定されるサブスクリプション数と追加のテーブル同期プロセスのためのスロットを考慮して十分な値を設定します。
max_wal_senders を、max_replication_slots クォータと現在の物理レプリカをサポートする値に設定します。
max_logical_replication_workers を、サブスクリプション数と、レプリケーションシステムがテーブル同期に必要とする追加のワーカー数をサポートする値に設定します。
max_worker_processes を、max_logical_replication_workers 値より 1 以上大きい値に設定します。例えば、max_logical_replication_workers が 25 の場合、max_worker_processes は 26 に設定します。
データコピーが遅い場合は、max_sync_workers_per_subscription の値を増やして、サブスクリプションの設定と新しいテーブル追加を処理する同期ワーカー数を制御します。

重要: 上記の変更を適用するには、Aurora PostgreSQL 互換 DB クラスターを再起動する必要があります。

パブリケーションとサブスクリプションの設定を確認する

論理レプリケーションパラメータを設定したら、パブリケーションとサブスクリプションが正しく設定されていることを確認します。パブリケーションに目的のテーブルがすべて含まれていること、サブスクリプションパラメータが正しく、レプリケーションユーザーに適切なアクセス許可があることを確認してください。

ソースデータベースに接続し、次のコマンドを実行します。

パブリケーションの設定を確認するには、次のコマンドを実行します。

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

サブスクリプションの設定を確認するには、次のコマンドを実行します。

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

レプリケーションスロットがアクティブであることを確認する

ソースデータベースに接続し、次のコマンドを実行します。

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

スロットが非アクティブであるか、過度な遅延を示している場合は、レプリケーションワーカーを確認して問題のトラブルシューティングを行います。

レプリケーションワーカーがアクティブであることを確認する

ターゲットデータベースに接続し、次のコマンドを実行します。

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

レプリケーションワーカーがない場合は、サブスクリプションを再起動してください。

サブスクリプションを無効にするには、次のコマンドを実行します。

ALTER SUBSCRIPTION subscription_name DISABLE;

サブスクリプションを有効にするには、次のコマンドを実行します。

ALTER SUBSCRIPTION subscription_name ENABLE;

サブスクリプションを再起動してもレプリケーションワーカーがない場合は、PostgreSQL エラーログでエラーメッセージを確認してください。

レプリケーションの進行状況と遅延をモニタリングする

パブリケーションでの大量のトランザクションや大きなトランザクションにより、レプリケーションに遅延が発生することがあります。または、パブリケーションまたはサブスクリプションに制約がある可能性があります。

レプリケーションが停止したのか、遅いのかを判断するには、数回の間隔でレプリケーションの進行状況をモニタリングします。

DB クラスターに接続し、次のコマンドを実行します。

パブリケーションのレプリケーション進行状況を確認するには、次のコマンドを実行します。

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

サブスクリプションのレプリケーション進行状況を確認するには、次のコマンドを実行します。

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

レプリケーション遅延を最小限に抑えるには、書き込みスルーキャッシュをモニタリングしてください。ワークロードに対してキャッシュサイズが不十分な場合は、rds.logical_wal_cache の値を手動で変更します。詳細については、「Achieve up to 17x lower replication lag with the new write-through cache for Aurora PostgreSQL」(Aurora PostgreSQL の新しい書き込みスルーキャッシュでレプリケーション遅延を最大 17 分の 1 に減らす) を参照してください。

リソース制約のモニタリング

パブリッシャーとサブスクライバーのリソース制約をトラブルシューティングするには、[拡張モニタリング] を有効にして、CPUUtilization、FreeableMemory、SwapUsage、および NetworkThroughput をモニタリングします。レプリケーションの問題が発生したときに通知を受けるように Amazon CloudWatch アラームを設定します。

詳細については、「Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換 DB インスタンスで、パフォーマンスの問題や実行速度が遅いクエリを特定してトラブルシューティングする方法を教えてください」を参照してください。

スキーマの不一致を特定してデータの不整合を解決する

ソースデータベースとターゲットデータベースに接続します。次に、レプリケートされたテーブルに列があり、データタイプに互換性があることを確認します。また、プライマリキーと一意の制約が一貫していることを確認してください。

サブスクリプションを有効にするには、次のコマンドを実行します。

ALTER SUBSCRIPTION subscription_name ENABLE;

テーブル定義を比較するには、両方のデータベースで次のコマンドを実行します。

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

注: your_table_name を実際のテーブル名に置き換えてください。

競合を解決する

ネイティブな PostgreSQL 論理レプリケーションでは、複数のパブリッシャーからのデータ競合や、ローカルで変更したデータと競合する、レプリケートされた変更を検出できません。同じキーを持つ既存の行がある場合、Aurora は更新を適用し、挿入は失敗します。

競合の原因を特定するには、PostgreSQL のログを確認してください。

次のログの例は、ターゲットデータベースに既に存在しているアセット ID のレコードを挿入しようとしたためにレプリケーションが失敗したことを示しています。

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

レプリケーションオリジンは pg_32796 で、論理シーケンス番号 (LSN) 0/6A12458 で終了します。

データを手動で修正するには、競合が発生した時点でレプリケーションを停止するか、disable_on_error オプションを使用してサブスクリプションを設定します。

または、ソースとターゲットのデータを確認して、競合の原因となった LSN をスキップできるかどうかを判断できます。次に、pg_replication_origin_advance() 関数を使用して、競合の原因となった LSN をスキップします。詳細については、PostgreSQL Web サイトの「pg_replication_origin_advance (node_name text, lsn pg_lsn)」を参照してください。

注: Aurora PostgreSQL 互換バージョン 15 以降は pg_replication_origin_advance() 関数をサポートしています。

LSN をスキップするには、次の手順を実行します。

次の SQL コマンドを実行して、サブスクリプションを一時的に無効にします。
```
ALTER SUBSCRIPTION subscription_name DISABLE;
```
注: disable_on_error オプションを使用してサブスクリプションを設定した場合、サブスクリプションはエラー発生後に自動的に無効になります。

次の pg_replication_origin_advance() 関数を使用して、オリジンを Finish_LSN+1 に進めてください。

SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

注: node_name を実際のノード名に置き換えてください。

サブスクリプションを有効にするには、次のコマンドを実行します。
```
ALTER SUBSCRIPTION subscription-name ENABLE;
```
注: subscription-name をサブスクリプション名に置き換えてください。

複数のデータ不整合を解決するには、ターゲットテーブルをクリーンアップし、パブリケーションとサブスクリプションを再設定する必要がある場合があります。