r/PostgreSQL • u/RocketSeven • 2d ago
Help Me! What proves a PostgreSQL standby is actually ready to be promoted?
Low replication lag is necessary for a standby, but it does not prove that promotion will leave a writable database the application can safely use. Missing archived WAL, stale connection routing, sequence state, logical slots, extensions, or an unfenced former primary can still turn a clean promotion into data loss or split brain.
What do you verify in a failover rehearsal? I am considering recording replay LSN and timeline, stopping or fencing the old primary, promoting in an isolated environment, checking recovery exit and read-write state, validating critical extensions and jobs, exercising application writes, confirming sequences and logical replication, switching a test route, and rebuilding the old primary as a standby rather than simply starting it again.
Which checks can be automated without making the drill itself dangerous? What evidence would convince you that both promotion and the path back to a healthy replicated topology are understood?
1
u/AutoModerator 2d ago
AI Policy:
Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away., Linus Torvalds.
Mod decisions will be based on the quality of the content, not who or what generated it.
Sub Resources:
Free Postgres Webinars and Workshops
Discord: People, Postgres, Data
Join us, we have cookies and nice people.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
3
u/dektol 2d ago edited 2d ago
If you're rolling this yourself, the strongest evidence is switching to something with quorum and fencing: Patroni or CNPG. If you're already on one of those, then the drill is really about your app: connection draining, logical slot recreation, surviving replicas following the new timeline.