Amazon RDS for PostgreSQL で recovery_min_apply_delay パラメータを使ったレプリケーションの遅延がサポートされました

いわさです。

Aamzon RDS for PostgreSQL はリードレプリカという読み取り専用インスタンスを生成し、レプリケーションを行う機能がサポートされています。

https://dev.classmethod.jp/articles/rds-postgresql-read-replica/

一方、PostgreSQL のレプリケーション関連のパラメータとしてrecovery_min_apply_delayというスタンバイインスタンス側のものがあります。
レプリケーションの挙動として、スタンバイインスタンスはできるかぎり早くプライマリインスタンスからデータをレプリケーションするのですが、このパラメータを指定することで明示的に一定時間遅らせることが出来ます。

https://www.postgresql.org/docs/current/runtime-config-replication.html

知らなかったのですが、Amazon RDS for PostgreSQL ではこれまでrecovery_min_apply_delayをサポートしていなかったみたいで、遅延レプリケーション構成を取ることが出来なかったようなのですが、先日のアップデートで使えるようになったとのことです。

https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-rds-postgresql-delayed-replica/

ユースケースとしては従来の PITR (ポイントインタイムリカバリ) よりも高速な復旧が必要になるケースで、遅延レプリケーションを有効化したインスタンスを昇格させることで実現することが出来ます。

リードレプリカを用意し、デフォルトのレプリケーションの様子を観察してみる

今回の機能ですが、以下のマイナーバージョン以降で利用が可能とのことなので、マイナーバージョンがサポートされているものをお使いか、注意しましょう。

• 14.19
• 15.14
• 16.10
• 17.6

今回は 17 の本日時点の最新マイナーバージョンである 17.6 で試してみます。

まずはプライマリインスタンスを作成します。
普通にリードレプリカを作るだけなので、シングル AZ インスタンスで作成します。

プライマリインスタンスが作成できたら、リードレプリカを作成しましょう。

プライマリインスタンスとリードレプリカインスタンスでそれぞれ別のエンドポイントが生えているので、それぞれにpsqlで接続して動作確認します。
テーブルとレコードを新規でいくつか作成してみましょう。

% psql -h hoge0824psql.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U postgres -d hogedb
Password for user postgres: 
psql (14.15 (Homebrew), server 17.6)
WARNING: psql major version 14, server major version 17.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

hogedb=> create table hogetbl (id integer, val varchar(10));
CREATE TABLE
hogedb=> insert into hogetbl values (1, 'a1');
INSERT 0 1
hogedb=> insert into hogetbl values (2, 'a2');
INSERT 0 1
hogedb=> insert into hogetbl values (3, 'a3');
INSERT 0 1
hogedb=> 

リードレプリカ側でクエリを投げてみるとすぐにレプリケーションされたレコードを確認することが出来ました。

% psql -h hoge0824psql2.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U postgres -d hogedb
Password for user postgres: 
psql (14.15 (Homebrew), server 17.6)
WARNING: psql major version 14, server major version 17.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

hogedb=> select * from hogetbl;
 id | val 
----+-----
  1 | a1
  2 | a2
  3 | a3
(3 rows)

hogedb=> 

Amazon RDS for PostgreSQL ではレプリケーションに関するラグを観測できるメトリクスがあるのですが、だいたい 100 ~ 300 ms くらいでレプリケーションされていました。

パラメータ変更し遅延レプリケーションを有効化

ここから今回のアップデートです。
パラメータグループでrecovery_min_apply_delayを設定しましょう。デフォルトでは何も設定されておらず、デフォルト値に挙動としては0になります。

今回は100000を設定しました。
遅延をミリ秒で指定するので 100 秒ということです。最大で86400000（24時間）まで指定が可能なので RPO に応じて調整できます。

パラメータタイプが Dynamic なのでインスタンスの再起動なしですぐに反映されます。
パラメータグループをアタッチしなおす場合は再起動が必要です。

遅延レプリケーション時の動作

パラメータ有効化後にレコードを追加してみます。
以下はプライマリインスタンスです。

hogedb=> insert into hogetbl values (4, 'a4');
INSERT 0 1
hogedb=> select * from hogetbl;
 id | val 
----+-----
  1 | a1
  2 | a2
  3 | a3
  4 | a4
(4 rows)

hogedb=> 

続いてその直後のリードレプリカインスタンスの様子です。

hogedb=> select * from hogetbl;
 id | val 
----+-----
  1 | a1
  2 | a2
  3 | a3
(3 rows)

おお。先ほどと異なり、変更内容がレプリケーションされていませんね。
その後 100 秒程度待機すると、次のように変更が反映されました。

hogedb=> select * from hogetbl;
 id | val 
----+-----
  1 | a1
  2 | a2
  3 | a3
  4 | a4
(4 rows)

遅延レプリケーション時の ReplicaLag

この遅延レプリケーション発生時は ReplicaLag が 100,000 ms 大きくなるのかなぁと思いきや、どうやらメトリクス上は関係ないみたいです。
次のように通常のレプリカラグと同じような様子をしていました。

レプリカラグによるアラームなどを設定する際はこの値は考慮しなくても良さそうですね。

さいごに

本日は Amazon RDS for PostgreSQL で recovery_min_apply_delay パラメータを使ったレプリケーションの遅延がサポートされたので使ってみました。

RTO 要件が PITR だとちょっと足りないという時には選択肢になりそうです。覚えておこう。
あとはレプリケーションラグが発生したときのアプリケーション挙動を確認する際などにも利用できるかもしれません。