These scripts demonstrate the command line interface, CLI, “pg_rewind” re-provisioning a formerly deprecated PRIMARY host, pg1, into a viable STANDBY. Although the scripts have been written expressly for a custom-made set of two Linux containers using CENTOS7, it has been written in a form that is hopefully clear and concise enough that they can be of use to you and can be customized to suit your particular needs.

There are five scripts:

  • 01.setup_lxc_environment.sh: Create two Linux containers from a custom made image
  • 02.setup_replication.sh: Setup a 2 node async replication cluster
  • 03.switchover.sh: Invoke a switchover i.e. stop pg1 and promote pg2
  • 04.reprovision_pg1.sh: Here’s where the magic takes place
  • 05.validate.sh: A simple test validating replication works correctly

Script 1: 01.setup_lxc_environment.sh

This script starts by destroying preexisting containers and rebuilding them from an already preexisting image that was custom-made, with postgres already installed. Although not necessary, the IP addresses for each container were hard-coded. Both containers have the postgres 12 binaries installed, with an already initialized data cluster.

Script 2: 02.setup_replication.sh

The two postgres configuration files, pg_hba.conf and postgresql.conf, are configured for remote access with verbose logging providing plenty of information and is set for replication service.

While all the runtime parameters are important, pay special attention to these three runtime parameters:

The CLI pg_receivewal is useful in a script because it can test if a slot has already been created, thus pg_basebackup simply looks for the slot and is not required to create one.

Script 03.switchover.sh

It’s more accurate to call this a switchover than a failover. Notice that a new WAL is generated on pg1 before it’s stopped.

Promoting the STANDBY, pg2, is extremely easy in postgres these days. Just log in as the superuser and execute the SQL “select pg_promote()”.

The final step to this script creates and populates a table with some records.

Script 04.reprovision_pg1.sh

And here’s where the magic takes place.

Just before rewinding pg1 begins, a slot is explicitly added to PRIMARY host pg2. Although in this particular instance it isn’t really needed to make the replication work, since runtime parameter “wal_keep_segments”, which no longer exists in postgres version 13, is configured to retain 60 WAL segments, more than enough WALS for this demonstration.

As soon as pg_rewind completes, host pg1 needs some final tuning preparing it for STANDBY service:

  • Configuration file postgresql.auto.conf is updated
  • Creating file standby.signal informs postgres that this host is meant to replicated from another one.

Script 05.validate.sh

Validation tests a number of conditions and includes:

  • Is pg1 a read-only standby?
  • Can we see the table that was created after pg2 was promoted?
  • Do we see the database that was created after pg1 was re-provisioned proving that replication is active?

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.

Download Percona Distribution for PostgreSQL Today!