3.2.3. WAL ディスク容量の消費
特定のケースでは、WAL ファイルが消費する PostgreSQL ディスク領域が急増するか、通常の比で増加する可能性があります。状況を説明する可能性のある理由は 3 つあります。
-
Debezium は、定期的に、処理されたイベントの LSN をデータベースに対して確認します。これは
pg_replication_slotsスロットテーブルのようconfirmed_flush_lsnに表示されます。データベースはディスク領域の回収を担当し、WAL サイズはrestart_lsn同じテーブルから計算できます。したがって、confirmed_flush_lsnが定期的に増加し、ラグの場合には、データベースは領域を回収する必要restart_lsnがあります。ディスク領域は通常バッチブロックで回収されるため、これは予想される動作であり、ユーザーの側での動作は必要ありません。 -
監視対象のデータベースには多くの更新がありますが、対象のテーブルやスキーマ、もしくはスキーマに関連するのは、逆累積量のみです。この状況は、
heartbeat.interval.ms設定オプションを使用して定期的なハートビートイベントを有効にすることで簡単に解決できます。 - PostgreSQL インスタンスには複数のデータベースが含まれ、その 1 つが高トラフィックのデータベースになります。Debezium は、他のデータベースと比較すると、トラフィックの低い別のデータベースを監視します。Debezium は LSN をデータベースごとにレプリケーションスロットが機能するため、Debezium が呼び出されないため、確認することができません。WAL はすべてのデータベースで共有されるため、Debezium が監視するデータベースがイベントを出力するまで拡大する傾向があります。
3 番目の原因を解決するには、
-
heartbeat.interval.ms設定オプションを使用した定期的なハートビートレコード生成を有効にします。 - Debezium が追跡するデータベースから変更イベントを定期的に出力します。
その後、別のプロセスはテーブルを定期的に更新します（新しいイベントを挿入するか、すべて同じ行を更新します）。その後、PostgreSQL は、最新の LSN を確認し、データベースが WAL 領域を回収できるようにする Debezium を呼び出します。このタスクは、heartbeat.action.query コネクターオプションを使用して自動化できます（下記参照）。
ヒント
Postgres を使用した AWS RDS のユーザーの場合、3 つ目の原因がアイドル環境で発生する可能性があります。これは、AWS RDS が独自のシステムテーブルに書き込みを行い、頻繁にユーザーに認識されないため（5 分）。イベントを定期的に出力すると、問題は解決されます。
