by Alicia Cozine, Anna Headley, Francis Kayiwa, and Trey Pendragon
In our previous post we described how to set up logical replication and use it as a migration strategy between different versions of PostgreSQL. Here we’ll describe how to set up streaming replication, for use as an always-up-to-date failover copy.
Two identical PostgreSQL 15 machines, named here as leader
and follower
REPLICATION
role attribute:
CREATE ROLE replication WITH REPLICATION LOGIN PASSWORD 'passwordhere';
/etc/postgresql/15/main/pg_hba.conf
on the leader, so it can accept connections from the follower:
host replication replication <follower_ip/32> md5
If you have more than one follower, you’ll need them all here too.
/etc/postgresql/15/main/pg_hba.conf
on the follower, so it can accept connections from the leader:
host replication replication <leader_ip/32> md5
If you have other followers, you’ll want them all here too. We only have one.
sudo service postgresql stop
rm -rf /var/lib/postgresql/15/main && /usr/bin/pg_basebackup -Xs -d "hostaddr=<leader_ip> port=5432 user=replication password=<passwordhere>" -D /var/lib/postgresql/15/main -v -Fp
standby.signal
file in the PostgreSQL 15 data directory to notify PostgreSQL to turn on in standby mode:
touch /var/lib/postgresql/15/main/standby.signal
Note: Other versions may have different ways of signalling standby mode. This is how it works in 15. You can check the documentation for your version.sudo service postgresql start
leader
, and query for it in the follower
and it should return.Now that we have completed our big migration, we are looking for ways to make our migration runbook more efficient. We did put the application in read-only mode, which might not be necessary next time if we use PGbouncer.
We are also looking to expand our understanding of PostgreSQL for really big databases. We want to know if we could get better performance, we want to be able to replicate production data into staging, we want to do isolated backup restoration (one table, one row), and we want reliability.