We have several PostgreSQL versions that support logical decoding to replicate data changes from a source database to a target database, which is a cool and very powerful tool that gives the option to replicate all the tables in a database, only one schema, a specific set of tables or even only some columns/rows, also is a helpful method for version upgrades since the target database can run on a different (minor or major) PostgreSQL version.
There are some cases when the databases have been hosted in the AWS Relational Database Service (RDS) which is the fully auto-managed solution offered by Amazon Web Services, there is no secret that choosing this option for our database backend comes with a level of vendor lock-in, and even when RDS offers some build-in replica solutions such as Multi-AZ or read-replicas sometimes we can take advantage of the benefits from logical replication.
In this post I will describe the simplest and basic steps I used to implement this replica solution avoiding the initial copy data from the source database to the target, creating the target instance from an RDS snapshot. Certainly, you can take advantage of this when you work with a big/huge data set and the initial copy could lead to high timeframes or network saturation.
NOTE: The next steps were tested and used for a specific scenario and they are not intended to be an any-size solution, rather give some insight into how this can be made and most importantly, to stimulate your own creative thinking.
In this exercise, I wanted to perform a version upgrade from PostgreSQL v11.9 to PostgreSQL v12.5, we can perform a direct upgrade using the build-in option RDS offers, but that requires a downtime window that can vary depending on some of the next:
During the direct upgrade process, RDS takes a couple of new snapshots of the source instance, firstly at the beginning of the upgrade and finally when all the modifications are done, depending on how old is the previous backup and how many changes have been made on the datafiles the pre backup could take some time. Also, if the instance is Multi-AZ the process should upgrade both instances, which adds more time for the upgrade, during most of these actions the database remains inaccessible.
The next is a basic diagram of how an RDS Multi-AZ instance looks, all the client requests are sent to the master instance, while the replica is not accessible and some tasks like the backups are executed on it.
Therefore, I choose logical replication as the mechanism to achieve the objective, we can aim for a quicker switch-over if we create the new instance in the desired version and just replicate all the data changes, then we need a small downtime window just to move the traffic from the original instance to the upgraded new one.
To be able to perform these actions we would need:
Per the title of this post, the next is the list of steps to set up a PostgreSQL logical replication between a PostgreSQL v11.9 and a v12.5 using an RDS snapshot to initialize the target database.
1. Verify the PostgreSQL parameters for logical replication
We require the next PostgreSQL parameters for this exercise
|
1 |
demodb=> select name,setting from pg_settings where name in (<br> 'wal_level',<br> 'track_commit_timestamp',<br> 'max_worker_processes',<br> 'max_replication_slots',<br> 'max_wal_senders') ;<br> name | setting<br>------------------------+---------<br> max_replication_slots | 10<br> max_wal_senders | 10<br> max_worker_processes | 10<br> track_commit_timestamp | on<br> wal_level | logical<br>(5 rows) |
NOTE: The parameter track_commit_timestamp can be optional since in some environments is not advisable for the related overhead, but it would help to track and resolve any conflict that may occur when the subscriptions are started.
2. Create the replication user and grant all the required privileges
|
1 |
demodb=> CREATE USER pgrepuser WITH password 'SECRET';<br>CREATE ROLE<br>demodb=> GRANT rds_replication TO pgrepuser;<br>GRANT ROLE<br>demodb=> GRANT SELECT ON ALL TABLES IN SCHEMA public TO pgrepuser;<br>GRANT |
3. Create the PUBLICATION
|
1 |
demodb=> CREATE PUBLICATION pglogical_rep01 FOR ALL TABLES;<br>CREATE PUBLICATION |
4. Create a REPLICATION SLOT
|
1 |
demodb=> SELECT pg_create_logical_replication_slot('pglogical_rep01', 'pgoutput');<br> pg_create_logical_replication_slot<br>------------------------------------<br> (pglogical_rep01,3C/74000060)<br>(1 row)<br> |
5. Create a new RDS snapshot
|
1 |
aws rds create-db-snapshot <br> --db-instance-identifier demodb-postgres<br> --db-snapshot-identifier demodb-postgres-to-125 |
6. Upgrade the RDS snapshot to the target version
|
1 |
aws rds modify-db-snapshot <br> --db-snapshot-identifier demodb-postgres-to-125 <br> --engine-version 12.5 |
7. Restore the upgraded RDS snapshot
Since we are moving from version 11.9 to 12.5 we may need to create a new DB parameter group if we are using some custom parameters.
From the instance describe we can verify the current parameter group
|
1 |
aws rds describe-db-instances <br> --db-instance-identifier demodb-postgres | <br>jq '.DBInstances | map({DBInstanceIdentifier: .DBInstanceIdentifier, DBParameterGroupName: .DBParameterGroups[0].DBParameterGroupName})'<br>[<br> {<br> "DBInstanceIdentifier": "demodb-postgres",<br> "DBParameterGroupName": "postgres11-logicalrep"<br> }<br>]<br> |
Then we can validate the custom parameters
|
1 |
aws rds describe-db-parameters <br> --db-parameter-group-name postgres11-logicalrep <br> --query "Parameters[*].[ParameterName,ParameterValue]" <br> --source user --output text <br>track_commit_timestamp 1 |
We need to create a new parameter group in the target version
|
1 |
aws rds create-db-parameter-group <br> --db-parameter-group-name postgres12-logicalrep <br> --db-parameter-group-family postgres12 |
Finally, we need to modify the parameters we got before in the new parameter group
|
1 |
aws rds modify-db-parameter-group <br> --db-parameter-group-name postgres12-logicalrep <br> --parameters "ParameterName='track_commit_timestamp',ParameterValue=1,ApplyMethod=immediate" |
Now we can use the new parameter group to restore the upgraded snapshot
|
1 |
aws rds restore-db-instance-from-db-snapshot <br> --db-instance-identifier demodb-postgres-125 <br> --db-snapshot-identifier demodb-postgres-to-125 <br> --db-parameter-group-name postgres12-logicalrep |
8. Get the LSN position from the target instance log
To list all the database logs for the new DB instance
|
1 |
aws rds describe-db-log-files <br> --db-instance-identifier demodb-postgres-125 |
We should pick the latest database log
|
1 |
aws rds download-db-log-file-portion <br> --db-instance-identifier demodb-postgres-125 <br> --log-file-name "error/postgresql.log.2021-03-23-18" |
From the retrieved log portion we need to find the value after for the log entry redo done at:
|
1 |
...<br>2021-03-23 18:19:58 UTC::@:[5212]:LOG: redo done at 3E/50000D08<br>... |
9. Create SUBSCRIPTION
|
1 |
demodb=> CREATE SUBSCRIPTION pglogical_sub01 CONNECTION 'host=demodb-postgres.xxxx.us-east-1.rds.amazonaws.com port=5432 dbname=demodb user=pgrepuser password=SECRET' PUBLICATION pglogical_rep01<br>WITH (<br> copy_data = false,<br> create_slot = false,<br> enabled = false,<br> connect = true,<br> slot_name = 'pglogical_rep01'<br>);<br>CREATE SUBSCRIPTION |
10. Advance the SUBSCRIPTION
We need to get the subscription id
|
1 |
demodb=> SELECT 'pg_'||oid::text AS "external_id"<br>FROM pg_subscription <br>WHERE subname = 'pglogical_sub01';<br> external_id<br>-------------<br> pg_73750<br>(2 rows)<br> |
Now advance the subscription to the LSN we got in step 8
|
1 |
demodb=> SELECT pg_replication_origin_advance('pg_73750', '3E/50000D08') ;<br>pg_replication_origin_advance<br>-------------------------------<br>(1 row) |
11. Enable the SUBSCRIPTION
|
1 |
demodb=> ALTER SUBSCRIPTION pglogical_sub01 ENABLE;<br>ALTER SUBSCRIPTION |
Once we are done with all the steps the data changes should flow from the source database to the target, we can check the status at the pg_stat_replication view.
Choosing DBaaS from cloud vendors bring some advantages and can speed up some implementations, but they come with some costs, and not all the available tools or solutions fits all the requirements, that is why always is advisable to try some different approaches and think out of the box, technology can go so far as our imagination.
Percona Distribution for PostgreSQL provides the best and most critical enterprise components from the open-source community, in a single distribution, designed and tested to work together.
Resources
RELATED POSTS
