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