Wal2json の構成
IBM Cloud® Databases for PostgreSQL デプロイメントでは、wal2json プラグインがサポートされており、論理デコード を有効にすることができます。 このプラグインは、PostgreSQL バージョン 9.6 および 10 では非推奨になり、PostgreSQL バージョン 11 および 12 でのみサポートされます。 プラグインはすでにインストールされていますが、使用するには配置とデータベースを設定する必要があります。
-
まず、、、および
wal_level
の各設定をmax_replication_slots
構成max_wal_senders
する必要があります。wal_level
をlogical
に変更します。max_replication_slots
とmax_wal_senders
の両方を 20 より大きい値に設定する必要があります。Databases for PostgreSQL は、現在および将来の運用のために、20 個のレプリケーション・スロットと WAL 送信者を予約しています。curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/configuration -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"configuration": { "wal_level": "logical", "max_replication_slots": 21, "max_wal_senders": 21 } }'
-
repl
ユーザーのパスワードを設定します。 ユーザーのパスワードは、Cloud Databases CLI プラグインのcdb deployment-user-password
コマンドまたは Cloud Databases API の/deployments/{id}/users/{username}
エンドポイントを使用して変更できます。repl
ユーザーには REPLICATION 特権があり、パスワードが設定されると、wal2json
プラグインはこれを使用します。 -
Cloud Databases API からデータベースにレプリケーション・スロットを作成します。
/deployments/{id}/postgresql/logical_replication_slots
エンドポイントに POST 要求を送信します。curl -X POST https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/postgresql/logical_replication_slots -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"logical_replication_slot": { "name": "<slot_name>", "database_name": "<database_name>", "plugin_type": "wal2json" } }'
プラグイン・タイプは
wal2json
でなければなりません。 データベースは既存のデータベースでなければなりません。 スロット名には小文字、数字、アンダースコアのみを使用することができます。 任意のデータベースに接続して実行することで、レプリケーション・スロットが存在するかどうかを確認できます。SELECT * FROM pg_replication_slots WHERE slot_name = '<slot_name>';
-
プラグインをテストするには、コマンドラインから
pg_recvlogical
を実行してください。 このコマンドは、PostgreSQL のインストールで使用できます。 デプロイメントのホストとポート、およびAPIで作成したデータベースとスロット名を使用します、PGSSLMODE=require pg_recvlogical -d <DATABASE NAME> -U repl -h <HOST> -p <PORT> --slot <SLOT NAME> --start -o pretty-print=1 -f -
-
ibmclouddb
で表を作成し、一部のデータを挿入します。 挿入がpg_recvlogical
を実行しているコマンドラインで行われることを確認してください。テーブルの作成が表示されない。
Wal2json に関する考慮事項とヒント
-
wal_level
をlogical
に設定すると、PostgreSQL では、論理デコードを実行するためにさらにデータを必要とすることから、WAL ファイルのサイズが増加します。wal2json
を使わない場合は、wal_level
はデフォルトのままにしておいてください。 WALファイルが大きくなると、より多くのディスク容量が必要になる可能性がある。 書き込みスループットが低下し、高可用性や読み取り専用レプリカに影響を与えるレプリケーションの遅延や、バックアップからのリストア時間が長くなる可能性があります。 -
論理デコードには、複製対象に関して一連の制限があります。 schema/DDL、シーケンス、TRUNCATE、およびラージ・オブジェクトなどがこれに含まれます。
-
制御された HA 切り替えが発生すると、複製イベントが複数回送信される可能性があります。 ダウンストリーム・アプリケーションは、複数回配信されるイベントを処理できなければなりません。
-
論理レプリケーション・スロットを作成し、コンシューマーが未接続で変更を消費していない場合は、デプロイメントでディスク・スペース不足になるリスクがあります。 レプリケーション・スロットは、コンシューマーが必要とする変更を含むすべてのトランザクション・ログを保持するように PostgreSQL に指示します。 これらの変更が消費されていない場合、PostgreSQL はディスク・スペース不足になるまで収集を続行します。 IBM Cloud® Monitoringの統合によって、ディスク・スペースをモニターすることができます。 スペースを使い尽くした場合は、ディスクのスケール・アップを行うことができます。これにより、データベースを開始できます。 その後、変更の消費を開始するか、スロットをドロップできます。
-
特定のレプリケーション・スロットによって使用されているディスク・スペースの量、およびそのレプリケーション・スロットにアクティブなコンシューマーがあるかどうかを確認できます。
admin
ユーザーを使用して、以下のコマンドのいずれかを実行します。PostgreSQL 10.x 以降
SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS lag, active from pg_replication_slots WHERE slot_type='logical';
PostgreSQL 9.x
SELECT slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) AS lag, active FROM pg_replication_slots WHERE slot_type='logical';
配置で予想以上のディスク使用量が表示された場合、レプリケーション スロットにコンシューマがあり、配置のディスク容量が不足していないことを確認して、トラブルシューティングを行います。