AWS AmazonRDS documentation change
Summary
Removed extensive documentation about logical decoding configuration, cascading read replicas setup, replication slot monitoring, and troubleshooting sections. Simplified content to focus on basic read replica limitations and corrected internal links.
Security assessment
The changes primarily remove technical implementation details about PostgreSQL replication features without introducing new security content or addressing specific vulnerabilities. The removed sections about logical replication configuration and replication slots were operational documentation rather than security advisories. No evidence of CVE fixes or vulnerability disclosures in the diff.
Diff
diff --git a/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.md b/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.md index 08381e7d2..59cea0fd1 100644 --- a//AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.md +++ b//AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.md @@ -5 +5 @@ -Logical decoding on a read replicaRead replica limitations with PostgreSQLRead replica configuration with PostgreSQLUsing cascading read replicasCreating cross-Region cascading read replicasHow replication works for different RDS for PostgreSQL versionsMonitoring and tuning the replication processTroubleshooting for RDS for PostgreSQL read replica +Read replica limitations with PostgreSQL @@ -13,106 +12,0 @@ Following, you can find information specific to working with read replicas with -## Logical decoding on a read replica - -RDS for PostgreSQL supports logical replication from standbys with PostgreSQL 16.1. This allows you to create logical decoding from a read-only standby that reduces the load on the primary DB instance. You can achieve higher-availability for your applications that need to synchronize data across multiple systems. This feature boosts the performance of your data warehouse and data analytics. - -Also, replication slots on a given standby persist the promotion of that standby to a primary. This means that in the event of a primary DB instance failover or the promotion of a standby to be the new primary, the replication slots will persist and the former standby subscribers will not be affected. - -###### To create logical decoding on a read replica - - 1. Turn on logical replication – To create logical decoding on a standby, you must turn on logical replication on your source DB instance and its physical replica. For more information, see Read replica configuration with PostgreSQL. - - * To turn on logical replication for a newly created RDS for PostgreSQL DB instance – Create a new DB custom parameter group and set the static parameter `rds.logical_replication` to `1`. Then, associate this DB parameter group with the Source DB instance and its physical read replica. For more information, see [Associating a DB parameter group with a DB instance in Amazon RDS](./USER_WorkingWithParamGroups.Associating.html). - - * To turn on logical replication for an existing RDS for PostgreSQL DB instance – Modify the DB custom parameter group of the source DB instance and its physical read replica to set the static parameter `rds.logical_replication` to `1`. For more information, see [Modifying parameters in a DB parameter group in Amazon RDS](./USER_WorkingWithParamGroups.Modifying.html). - -###### Note - -You must reboot the DB instance to apply these parameter changes. - -You can use the following query to verify the values for `wal_level` and `rds.logical_replication` on the source DB instance and its physical read replica. - - Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication'); - - name | setting - -------------------------+--------- - rds.logical_replication | on - wal_level | logical - (2 rows) - - - 2. Create a table in the source database – Connect to the database in your source DB instance. For more information, see [Connecting to a DB instance running the PostgreSQL database engine](./USER_ConnectToPostgreSQLInstance.html). - -Use the following queries to create table in your source database and to insert values: - - Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY); - CREATE TABLE - - Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000)); - INSERT 0 10000 - - 3. Create a publication for the source table – Use the following query to create a publication for the table on the source DB instance. - - Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test; - CREATE PUBLICATION - -Use a SELECT query to verify the details of the publication that was created on both the source DB instance and the physical read replica instance. - - Postgres=>SELECT * from pg_publication; - - oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot - -------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------ - 16429 | testpub | 16413 | f | t | t | t | t | f - (1 row) - - 4. Create a subscription from logical replica instance – Create another RDS for PostgreSQL DB instance as the logical replica instance. Make sure that VPC is setup correctly to ensure that this logical replica instance can access the physical read replica instance. For more information, see [Amazon VPC and Amazon RDS](./USER_VPC.html). If your source DB instance is idle, connectivity issues might occur and the primary doesn't send the data to standby. - - Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port - dbname=source_db_name user=user password=password' PUBLICATION testpub; - NOTICE: created replication slot "testsub" on publisher - CREATE SUBSCRIPTION - - Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY); - CREATE TABLE - -Use a SELECT query to verify the details of the subscription on the logical replica instance. - - Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription; - - oid | subname | subenabled | subslotname | subpublications - -------+---------+------------+-------------+----------------- - 16429 | testsub | t | testsub | {testpub} - (1 row) - postgres=> select count(*) from LR_test; - count - ------- - 10000 - (1 row) - - - 5. Inspect logical replication slot state – You can only see the physical replication slot on your source DB instance. - - Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; - - slot_name | slot_type | confirmed_flush_lsn - ---------------------------------------------+-----------+--------------------- - rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical | - (1 row) - -However, on your read replica instance, you can see the logical replication slot and the `confirmed_flush_lsn` value changes as the application actively consumes logical changes. - - Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; - - slot_name | slot_type | confirmed_flush_lsn - -----------+-----------+--------------------- - testsub | logical | 0/500002F0 - (1 row) - - Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; - - slot_name | slot_type | confirmed_flush_lsn - -----------+-----------+--------------------- - testsub | logical | 0/5413F5C0 - (1 row) - - - - @@ -125 +19 @@ The following are limitations for PostgreSQL read replicas: - * You can't create a read replica from another read replica if your RDS for PostgreSQL DB instance is running a PostgreSQL version earlier than 14.1. RDS for PostgreSQL supports cascading read replicas on RDS for PostgreSQL version 14.1 and higher releases only. For more information, see Using cascading read replicas with RDS for PostgreSQL. + * You can't create a read replica from another read replica if your RDS for PostgreSQL DB instance is running a PostgreSQL version earlier than 14.1. RDS for PostgreSQL supports cascading read replicas on RDS for PostgreSQL version 14.1 and higher releases only. For more information, see [Using cascading read replicas with RDS for PostgreSQL](./USER_PostgreSQL.Replication.ReadReplicas.Cascading.html). @@ -129 +23 @@ The following are limitations for PostgreSQL read replicas: - * If you promote a PostgreSQL read replica from within a replication chain (a series of cascading read replicas), any existing downstream read replicas continue receiving WAL files from the promoted instance automatically. For more information, see Using cascading read replicas with RDS for PostgreSQL. + * If you promote a PostgreSQL read replica from within a replication chain (a series of cascading read replicas), any existing downstream read replicas continue receiving WAL files from the promoted instance automatically. For more information, see [Using cascading read replicas with RDS for PostgreSQL](./USER_PostgreSQL.Replication.ReadReplicas.Cascading.html). @@ -142,367 +35,0 @@ The following are limitations for PostgreSQL read replicas: -## Read replica configuration with PostgreSQL - -RDS for PostgreSQL uses PostgreSQL native streaming replication to create a read-only copy of a source DB instance. This read replica DB instance is an asynchronously created physical replica of the source DB instance. It's created by a special connection that transmits write ahead log (WAL) data from the source DB instance to the read replica. For more information, see [Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) in the PostgreSQL documentation. - -PostgreSQL asynchronously streams database changes to this secure connection as they're made on the source DB instance. You can encrypt communications from your client applications to the source DB instance or any read replicas by setting the `ssl` parameter to `1`. For more information, see [Using SSL with a PostgreSQL DB instance](./PostgreSQL.Concepts.General.SSL.html) . - -PostgreSQL uses a _replication_ role to perform streaming replication. The role is privileged, but you can't use it to modify any data. PostgreSQL uses a single process for handling replication. - -You can create a PostgreSQL read replica without affecting operations or users of the source DB instance. Amazon RDS sets the necessary parameters and permissions for you, on the source DB instance and the read replica, without affecting the service. A snapshot is taken of the source DB instance, and this snapshot is used to create the read replica. If you delete the read replica at some point in the future, no outage occurs. - -You can create up to 15 read replicas from one source DB instance within the same Region. As of RDS for PostgreSQL 14.1, you can also create up to three levels of read replica in a chain (cascade) from a source DB instance. For more information, see Using cascading read replicas with RDS for PostgreSQL. In all cases, the source DB instance needs to have automated backups configured. You do this by setting the backup retention period on your DB instance to any value other than 0. For more information, see [Creating a read replica](./USER_ReadRepl.Create.html). - -You can create read replicas for your RDS for PostgreSQL DB instance in the same AWS Region as your source DB instance. This is known as _in-Region_ replication. You can also create read replicas in different AWS Regions than the source DB instance. This is known as _cross-Region_ replication. For more information about setting up cross-Region read replicas, see [Creating a read replica in a different AWS Region](./USER_ReadRepl.XRgn.html). The various mechanisms supporting the replication process for in-Region and cross-Region differ slightly depending on the RDS for PostgreSQL version as explained in How streaming replication works for different RDS for PostgreSQL versions. - -For replication to operate effectively, each read replica should have the same amount of compute and storage resources as the source DB instance. If you scale the source DB instance, be sure to also scale the read replicas. - -Amazon RDS overrides any incompatible parameters on a read replica if they prevent the read replica from starting. For example, suppose that the `max_connections` parameter value is higher on the source DB instance than on the read replica. In that case, Amazon RDS updates the parameter on the read replica to be the same value as that on the source DB instance. - -RDS for PostgreSQL read replicas have access to external databases that are available through foreign data wrappers (FDWs) on the source DB instance. For example, suppose that your RDS for PostgreSQL DB instance is using the `mysql_fdw` wrapper to access data from RDS for MySQL. If so, your read replicas can also access that data. Other supported FDWs include `oracle_fdw`, `postgres_fdw`, and `tds_fdw`. For more information, see [Working with the supported foreign data wrappers for Amazon RDS for PostgreSQL](./Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.html). - -### Using RDS for PostgreSQL read replicas with Multi-AZ configurations - -You can create a read replica from a single-AZ or Multi-AZ DB instance. You can use Multi-AZ deployments to improve the durability and availability of critical data, with a standby replica. A _standby replica_ is a dedicated read replica that can assume the workload if the source DB fails over. You can't use your standby replica to serve read traffic. However, you can create read replicas from high-traffic Multi-AZ DB instances to offload read-only queries. To learn more about Multi-AZ deployments, see [Multi-AZ DB instance deployments for Amazon RDS](./Concepts.MultiAZSingleStandby.html). - -If the source DB instance of a Multi-AZ deployment fails over to a standby, the associated read replicas switch to using the standby (now primary) as their replication source. The read replicas might need to restart, depending on the RDS for PostgreSQL version, as follows: - - * PostgreSQL 13 and higher versions – Restarting isn't required. The read replicas are automatically synchronized with the new primary. However, in some cases your client application might cache Domain Name Service (DNS) details for your read replicas. If so, set the time-to-live (TTL) value to less than 30 seconds. Doing this prevents the read replica from holding on to a stale IP address (and thus, prevents it from synchronizing with the new primary). To learn more about this and other best practices, see [Amazon RDS basic operational guidelines](./CHAP_BestPractices.html#CHAP_BestPractices.DiskPerformance). - - * PostgreSQL 12 and all earlier versions – The read replicas restart automatically after a fail over to the standby replica because the standby (now primary) has a different IP address and a different instance name. Restarting synchronizes the read replica with the new primary. - - - - -To learn more about failover, see [Failing over a Multi-AZ DB instance for Amazon RDS](./Concepts.MultiAZ.Failover.html). To learn more about how read replicas work in a Multi-AZ deployment, see [Working with DB instance read replicas](./USER_ReadRepl.html). - -To provide failover support for a read replica, you can create the read replica as a Multi-AZ DB instance so that Amazon RDS creates a standby of your replica in another Availability Zone (AZ). Creating your read replica as a Multi-AZ DB instance is independent of whether the source database is a Multi-AZ DB instance. - -## Using cascading read replicas with RDS for PostgreSQL - -As of version 14.1, RDS for PostgreSQL supports cascading read replicas. With _cascading read replicas_ , you can scale reads without adding overhead to your source RDS for PostgreSQL DB instance. Updates to the WAL log aren't sent by the source DB instance to each read replica. Instead, each read replica in a cascading series sends WAL log updates to the next read replica in the series. This reduces the burden on the source DB instance. - -With cascading read replicas, your RDS for PostgreSQL DB instance sends WAL data to the first read replica in the chain. That read replica then sends WAL data to the second replica in the chain, and so on. The end result is that all read replicas in the chain have the changes from the RDS for PostgreSQL DB instance, but without the overhead solely on the source DB instance. - -You can create a series of up to three read replicas in a chain from a source RDS for PostgreSQL DB instance. For example, suppose that you have an RDS for PostgreSQL 14.1 DB instance, `rpg-db-main`. You can do the following: - - * Starting with `rpg-db-main`, create the first read replica in the chain, `read-replica-1`. - - * Next, from `read-replica-1`, create the next read replica in the chain, `read-replica-2`. - - * Finally, from `read-replica-2`, create the third read replica in the chain, `read-replica-3`. - - - - -You can't create another read replica beyond this third cascading read replica in the series for `rpg-db-main`. A complete series of instances from an RDS for PostgreSQL source DB instance through to the end of a series of cascading read replicas can consist of at most four DB instances. - -For cascading read replicas to work, turn on automatic backups on your RDS for PostgreSQL. Create the read replica first and then turn on automatic backups on the RDS for PostgreSQL DB instance. The process is the same as for other Amazon RDS DB engines. For more information, see [Creating a read replica](./USER_ReadRepl.Create.html). - -As with any read replica, you can promote a read replica that's part of a cascade. Promoting a read replica from within a chain of read replicas removes that replica from the chain. For example, suppose that you want to move some of the workload off of your `rpg-db-main` DB instance to a new instance for use by the accounting department only. Assuming the chain of three read replicas from the example, you decide to promote `read-replica-2`. The chain is affected as follows: - - * Promoting `read-replica-2` removes it from the replication chain. - - * It is now a full read/write DB instance. - - * It continues replicating to `read-replica-3`, just as it was doing before promotion. - - * Your `rpg-db-main` continues replicating to `read-replica-1`. - - - - -For more information about promoting read replicas, see [Promoting a read replica to be a standalone DB instance](./USER_ReadRepl.Promote.html). - -###### Note - - * RDS for PostgreSQL doesn't support major version upgrades for cascading replicas. Before performing a major version upgrade, you need to remove cascading replicas. You can recreate them after completing the upgrade on your source DB instance and first-level replicas. - - * For cascading read replicas, RDS for PostgreSQL supports 15 read replicas for each source DB instance at first level of replication, and 5 read replicas for each source DB instance at the second and third level of replication. -