Postgresql failback without resync the data directory

Question

Im using Master slave streaming replication in PostgreSQL. Repmgr is configured to handle automatic failover.

Once the failover happened I need to make the old master as a slave without doing any basebackup, also the new primary requires some changes to act as a master like need to enable wal logs and other things.

How can I avoid these changes in Secondary during replicate to Old master and sync Old master without basebackup?

Answer 1

Fundamentally, you can't without some kind of reset of the old master. Unless the old master is shut down before the new master is promoted and you ensure all WAL is synced from old to new master, the old will usually be slightly "ahead" of the newly promoted replica at the point where the replica is promoted onto a new timeline.

It will refuse to start replaying from the new master because doing so would corrupt the old master. The old master might have assigned transaction ID 1234 already. So what should it do if the new master says "I'm starting transaction 1234". It already has 1234! There are similar issues all over, at the low level crash safety parts of the system.

That's why you usually re-sync the old master from the new master before starting it up. This can be made a lot faster with rsync or one of the parallel variants.

However, you can instead use pg_rewind to "wind back" the old master to the point where its history diverged from the new master, so it can start replaying from the new master. I don't use it myself, so I can't do much more than point you at it. But one of my colleagues wrote a couple of blog posts that could help you:

• Back to the Future Pt. 1: Introduction to pg_rewind
• Back to the Future Pt. 2: How to use pg_rewind with PostgreSQL 9.5

repmgr can use pg_rewind with repmgr standby switchover. As far as I know it does not do so with auto-failover, but you might want to ask the repmgr team for clarification on that.

Personally I think auto-failover is a terrible idea unless you also trigger it randomly during your normal operations, so you always know it works. ChaosMonkey-style. Otherwise it's just a recipe for doubling your disasters. Prefer manually-triggered automated failover, with something like repmgr standby switchover, and alerting to tell you when something's wrong.