この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
PostgreSQLは9.2からスタンバイからスタンバイへと多段でレプリケーションするカスケードレプリケーションに対応しています。 本機能が、Amazon RDS PostgreSQL 14.1 以降で利用できるようになりました。
レプリカをこれまでの約30倍の155個までもてるようになって参照性能が大幅に向上し、クロスリージョンレプリケーションすることでDR構成を組みやすくなりました。
カスケードレプリケーションとは
カスケードレプリケーションはレプリカから別のレプリカへと多段で非同期にレプリケーションする仕組みです。 WALデータ(トランザクションログ)はレプリケーションを直接組んでいるインスタンス間でのみ送信されるため、プライマリインスタンスへの負荷・帯域を増やすことなくレプリカを増やし、参照性能を増やすことができます。
Amazon RDS PostgreSQLでは PostgreSQL 14.1 以降でカスケードレプリケーションを利用できます。
Amazon RDSのインスタンスが持てるレプリカは最大で5台のままですが、3段まで多段レプリケーションを組めるため(depth=3)、レプリカを最大で 5 + 25 + 125 = 155インスタンスまで持てます。
従来は5個までしかレプリカを持てなかったため、カスケードを利用することで、レプリカ最大数が約30倍と参照性能が大幅に増えました。
クロスリージョンレプリケーションにも適用できます。
プライマリにレプリカを追加するときと同じく、ソースとなるインスタンスは自動バックアップを有効にする必要があります。
やってみた
1. 14.1 以降のRDS PostgreSQLを起動
バージョン 14.1 以降の RDS PostgreSQL を起動します。
レプリカを追加するには、自動バックアップを有効にする必要があるため、 「Backup retention period」を「1 day」以上にします。
この時点ではレプリカが存在しないため、インスタンスの Role は Instance です。
2. レプリカを追加
起動したインスタンスに対して、Action メニューの Create read replica からレプリカを追加します。
#1 で起動したインスタンスの Role は Parimary、追加したレプリカの Role は Replica となります。
3. レプリカの自動バックアップを有効化
繰り返しとなりますが、RDSインスタンスにレプリカを追加するには、自動バックアップを有効にする必要があります。
デフォルトではバックアップを取らない設定になっているため、「Backup retention period」を「0 days」から「1 day」以上に変更します。
4. レプリカ・インスタンスにレプリカを追加
レプリカインスタンスの自動バックアップを有効にすると、レプリカインスタンスにレプリカを追加できるようになります(カスケード・レプリケーション)。
Action メニューの Create read replica からレプリカを追加します。
#1 で起動したインスタンスの Role は Parimary のまま、#2 で追加したレプリカの Role は Replica から Source, Replica に変化、 #4 で追加したレプリカの Role は Replica となります。
確かに、カスケードレプリケーションを組めています。
この downstream インスタンスに対して pg_stat_wal_receiver を取得してみましょう。
test=> SELECT * FROM pg_stat_wal_receiver;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid | 12526
status | streaming
receive_start_lsn | 0/18000000
receive_start_tli | 1
written_lsn | 0/300002D8
flushed_lsn | 0/300002D8
received_tli | 1
last_msg_send_time | 2022-05-05 14:10:05.794971+00
last_msg_receipt_time | 2022-05-05 14:10:05.789466+00
latest_end_lsn | 0/300002D8
latest_end_time | 2022-05-05 14:09:35.607055+00
slot_name | rds_eu_central_1_db_e6mp5dt7uavox4oix2623iyjsa
sender_host | 10.10.1.110
sender_port | 5432
conninfo | user=rdsrepladmin password=******** channel_binding=prefer dbname=replication host=10.10.1.110 port=5432 fallback_application_name=walreceiver sslmode=prefer sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=whatever target_session_attrs=anysender_host の IPアドレスは #2 で追加したレプリカの IP アドレスです。
RDSをプロビジョンした VCP は CIDR が 172.0.0.0/16 ですが、10.10 の IP アドレスが割り振られていました。
カスケードレプリケーション・チェーン内のレプリカをプロモートするとどうなる?
parimary(rpg-db-main) -> replica(read-replica-1) -> replica(read-replica-2) -> replica(read-replica-3) というカスケードレプリケーション構成があったとします。
このレプリケーションチェインを構成するレプリカ(read-replica-2)を昇格させるとどうなるのでしょうか?
この場合、昇格したインスタンスにぶら下がるレプリカとのレプリケーションは維持されます。
PostgreSQL のデフォルトの挙動ですね。
If an upstream standby server is promoted to become the new primary, downstream servers will continue to stream from the new primary if recovery_target_timeline is set to 'latest' (the default).
https://www.postgresql.org/docs/current/warm-standby.html#CASCADING-REPLICATION
この特性を活かし、クロスリージョンでカスケード・レプリケーション構成をとると、プライマリ・リージョンの障害発生時に、セカンダリ・リージョンのレプリカを昇格させるDR構成を組めます。
制限
14.1 より古いバージョンではレプリカのバックアップを有効にできない
RDS ではレプリカを追加するには、ソースとなるインスタンスの自動バックアップを有効にする必要があります。
カスケードレプリケーションを使わない限り、レプリカにレプリカを追加することはないため、カスケードレプリケーションに対応していない古いバージョンのインスタンスに対して、バックアップを有効にしようとすると、次のエラーが発生します。
Automated backups aren't supported for read replicas running PostgreSQL versions lower than 14.
カスケードレプリケーションの深さは3段階まで
PostgreSQLのネイティブ機能としては、深さに制限はありません。
Cascading replication does not place limits on the number or arrangement of downstream servers
https://www.postgresql.org/docs/current/warm-standby.html#CASCADING-REPLICATION
Amazon RDS版では、カスケードレプリケーションの多段構成は3段までです。
4段目のレプリカを追加しようとすると、次のエラーが発生します。
最後に
Amazon RDS PostgreSQLが多段荷レプリケーションを組めるカスケードレプリケーションに対応しました。
参照性能をスケールアウトさせたい場合やDR目的でセカンダリリージョンにホットスタンバイさせたい場合などにご活用ください。
特に、サービスと参照主体の分析系システムが同居している場合、既存システムへのインパクトを最小限に抑えながら、分析系システム向けDBインスタンスを増やしやすいのではないかと思います。
1
