- Denish Patel
- 27th October 2015
- conference, postgresql
On #postgresql IRC channel, someone was having problem bringing up standby database server from backups taken using pg_basebackup and recovery.conf was configured to use replication slot.
The reporter was following below steps:
- Set max_replication_slots=5, wal_keep_segments=0 and restart primary database
- create replication slot :
SELECT * FROM pg_create_physical_replication_slot('standby')
- Call pg_basebackup -D – -Ft | bzip2 > backup.tar.bz2
- copy backup.tar.bz2 to standby server
- start postgresql on standby
The standby server was throwing following error during startup ..
requested WAL segment 000000010000000C000000AE has already been removed.
Question from Reporter:
Should I set wal_keep_segments to some non-zero value if I want to use replication slots because while reading docs I understand that I shouldn’t set wal_keep_segments if I use max_replication_slots?
Short answer :
As of now, pg_basebackup doesn’t have support for replication slot so it doesn’t have details on status of WAL files being created or removed.
While the feature is being worked on, you can use one of the following solutions to get around the problem for now.
On primay database server, set wal_keep_segments to some sane value relative to database traffic volume and time to make & transfer backup to bring up standby server. This setting will keep # of WAL files around on the primary server and will not delete them so when you bring up standby server using replication slot, it will start applying WAL files and eventually connect to physical slot created.
Create slot before taking backup and use the slot at the least once so primary db server will keep the WAL files around.
- On primary db server, create slot
- connect to slot using pg_receivexlog
/usr/pgsql-9.4/bin/pg_receivexlog -h primary-db-server -p 5432 -U replication –S 'standby1' -n -v -D /var/lib/pgsql/9.4/archive
- You can kill the pg_recievexlog process
- Take backup using pg_basebackup
- copy the backup and startup standby database
- The standby database should be able to connect to slot now!
- Don’t forget to drop the slot otherwise Primary DB server will keep the WALs indefinitely
I would prefer Solution #2 over Solution #1 because you don’t have to figure out optimal value for wal_keep_segments. Plus, you can use pg_receivexlog method for permanent archive solution. If you want to get more details, I will be presenting tutorial on replication topic “Out of the Box replication in Postgres 9.4” at Postgres Conference in San Francisco on Nov 17-18th. I will be provide hands on tutorial to setup robust replication for production db servers without using any third party tools in Postgres 9.4
If you haven’t registered, this is the time to register because the conference schedule looks amazing! You could still register with the discount code SeeMeSpeak which provides a 20% discount.
Let me know, if you have better solutions than I discussed in the post. I’m looking forward to see you at the conference.
- Running VACUUM FULL in Non-blocking Mode
- Connection Scaling
- PSQL Helper: Managing Connections and Simplifying Queries
- Vacuum Those MVs!
- Working With Repmgr: Using Other 3rd Party Tools for Setting up a Standby
- Working with Amazon Aurora PostgreSQL: dag, standby rebooted again!
- Working with Amazon Aurora PostgreSQL: what happened to the stats?
- How to set application_name for psql command line utility?
- Is there a limit on number of partitions handled by Postgres?
- Postgres 11 partitioning
pg_basebackup –slot has been committed as of 0dc848b and will be present in 9.6.
It’s important to *drop the slot when you’re done*, otherwise your server will continue to accumulate WAL indefinitely.
This is one of the reasons why it’d be good to teach pg_basebackup to handle slots its self.
Ideally we’d also have the idea of a transient slot that’s dropped when the connection drops, so that users whose pg_basebackup failed or was terminated prematurely didn’t have dangling slots lying around. We don’t need to repeat the user confusion around pg_multixact.
Good point, Craig. Updated steps.
Leave a comment