Follow my Leader connecting Postgres client applications after server failover
summary
Explains concrete options for reconnecting Postgres clients after failover: use driver multi-host URLs (many drivers and Go lack full support), provide a stable address via network load balancer, or move a virtual IP that follows leader with keepalived or PostgreSQL Virtual IP Manager. Recommends PG Bouncer/PGPool/ProxySQL for pooling and to turn downtime into latency because PG Bouncer can pause connections; cites a bank project that fronted a Go app with PG Bouncer and it worked, and suggests Patroni+service discovery for automation.
AI-written summary · about
chapters (19)
- 0:00Client reconnection after failovers
- 1:06Evolution of DB connections
- 3:35Components in application and database architecture
- 4:39Managing failover connections
- 5:20Finding the leader in PostgreSQL
- 7:07Stable addresses for failover
- 8:33Distributing connections
- 10:38Connection pooling benefits
- 11:40Proxies protecting the server
- 13:05Proxies reducing downtime
- 14:27Routing by read/write type
- 16:55Proxy complexity in PostgreSQL
- 17:16Team roles in failover
- 18:21Client reconnection options
- 20:51Network load balancer challenges
- 21:12VM solution limitations
- 22:16Server-side stable address
- 23:17Failover with service discovery
- 24:20Future protocol improvements
related talks
46mPgBouncer Connection Pooling and Routing
50mThe Immortal Postgres Web
47mPostgreSQL High Availability: The Considerations and the Candidates
55mHigh Availability with PostgreSQL and Pacemaker
50mMoving from MSSQL to pgSQL – High Availability and Disaster Recovery
57mReliability features in Postgres Pro
52mOverview of Solutions for PostgreSQL High Availability
13mBuilding reliable infrastructure with Postgres