AWS DMS CDC タスクを実行すると、ソース PostgreSQL データベースのストレージ消費量が多くなる理由を教えてください

簡単な説明

PostgreSQL を CDC タスクのソースとして使用する場合、AWS DMS は PostgreSQL 論理レプリケーションスロットを使用してソースデータベースから変更を取得します。WAL を PostgreSQL ソースに接続していない場合でも、スロットには AWS DMS が必要とする先行書き込みログ (WAL) が保持されます。AWS DMS は、レプリケーションスロットから必要な変更を取得し、レプリケーションスロットの restart_lsn を進めた後にのみ PostgreSQL から WAL を削除します。

詳細については、PostgreSQL Webサイトの「Logical decoding concepts (論理デコードの概念)」を参照してください。

ストレージボリュームの問題は次の理由で発生する可能性があります。

• AWS DMS CDC タスクを長時間停止している。AWS DMS をソースデータベースに接続しない場合、ソースのレプリケーションスロットからの変更は消費されません。そのため、PostgreSQL は継続的に WAL を保持します。
• WAL が過剰に生成されるような大きな負荷がかかっている。論理レプリケーションスロットを使用する場合、レプリケーションスロットにログシーケンス番号 (LSN) が必要な場合、PostgreSQL は WAL を保持します。
• アイドル状態のレプリケーションスロットがある。レプリケーションスロットが非アクティブな場合でも、レプリケーションスロットが保持する WAL には、テーブル、スキーマ、またはデータベースに関する情報が含まれています。これにより、テーブルにトランザクションがない場合でも、ソースのストレージがいっぱいになります。

解決策

レプリケーションスロットが、PostgreSQL ソースのディスク容量使用率が高くなる原因になっていないか確認する

レプリケーションスロットが PostgreSQL データベースのディスク容量使用率が高い原因になっているかどうかを確認するには、以下のクエリのいずれかを実行します。

PostgreSQL v9:

psql=> SELECT slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) AS replicationSlotLag, active FROM pg_replication_slots ;

PostgreSQL v10 以降:

psql=> SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS replicationSlotLag, active FROM pg_replication_slots ;

出力例:

slot_name                                                      | replicationslotlag | active---------------------------------------------------------------+--------------------+--------
xc36ujql35djp_00013322_907c1e0a_9f8b_4c13_89ea_ef0ea1cf143d    | 129 GB             | f
7pajuy7htthd7sqn_00013322_a27bcebf_7d0f_4124_b336_92d0fb9f5130 | 704 MB             | t
zp2tkfo4ejw3dtlw_00013322_03e77862_689d_41c5_99ba_021c8a3f851a | 624 MB             | t

レプリケーションスロットのアクティブ状態が f (false) に設定されている場合、データベースはそのスロットを消費していません。

使われていないスロットを削除するには、次のクエリを実行します。

psql=> SELECT pg_drop_replication_slot('YOUR_SLOTNAME');

注: YOUR_SLOTNAME を実際のスロット名に置き換えます。

詳細については、「Amazon RDS for PostgreSQL で "デバイスに空き領域がありません" や "DiskFull" というエラーが発生する理由を知りたいです」を参照してください。

WAL ハートビート機能を有効にする

PostgreSQL ソースデータベースのストレージ消費量を減らすには、heartbeatEnable 追加の接続属性 (ECA) を有効にします。この属性は、PostgreSQL ソースでストレージがいっぱいになるのを防ぐのに役立ちます。

WAL ハートビート機能を有効にするには、PostgreSQL ソースエンドポイントに次の ECA を追加します。

heartbeatEnable=Y;

注: ハートビートトランザクションは、AWS DMS タスクが実行されている場合にのみソースで実行されます。AWS DMS タスクを停止すると、WAL ハートビート機能は効果がありません。

次の ECA も指定できます。

heartbeatFrequency=frequency;heartbeatSchema=schemaname;

HeartbeatFrequency 属性は、ハートビートトランザクションがPostgreSQLソース上で実行される頻度を分単位で決定します。frequency は、トランザクションを実行させたい頻度に置き換えてください。たとえば、heartbeatFrequencyを 15 に設定すると、AWS DMS はソースで 15 分ごとにハートビートトランザクションを実行します。

HeartbeatSchema 属性は、AWS DMS がハートビートトランザクションを生成するためにデータベースオブジェクトを作成するデータベーススキーマを指定します。schemaname をご使用のデータベーススキーマに置き換えてください。

PostgreSQL のスロットの最大サイズを設定する

PostgreSQL バージョン 13 以降では、ソースデータベースに max_slot_wal_keep_size を適用できます。これにより、レプリケーションスロットが保持できる WAL の最大数が設定されます。詳細については、PostgreSQL ウェブサイトの「max_slot_wal_keep_size」を参照してください。

注: max_slot_wal_keep_size の設定は、PostgreSQL ソースでストレージがいっぱいになる問題を回避するのに役立ちます。ただし、AWS DMS CDC タスクがレプリケーションスロットから変更を読み取る前に、PostgreSQL ソースデータベースが WAL を削除する可能性があります。これにより、タスクが失敗する可能性があります。

関連情報

Hevo ウェブサイトの「Types of PostgreSQL Replication Slots (PostgreSQL レプリケーションスロットの種類」