Patroni Deployment Patterns
summary
Patroni manages Postgres high availability using a distributed consensus store (etcd/Consul/ZooKeeper or the deprecated pync raft) plus a REST API and integrates with Kubernetes operators and HAProxy. Recommended deployments use 3 DCS nodes, keep key TTL (~30s) and loop/retry settings tuned, and expect pg_rewind on rejoin and automatic replication slot TTL (~30min). For multi‑region either run one stretched cluster (needs three regions for safe auto failover) or separate standby clusters; fail‑safe mode lets a primary continue when DCS is unreachable; synchronous quorum supports stricter commit guarantees.
AI-written summary · about
chapters (8)
- 0:00Introduction to Patroni
- 2:09Patroni features and setup
- 10:05Architecture and leader election
- 17:48Deployment topologies
- 25:21Advanced management and configuration
- 42:43Multi-datacenter deployments
- 46:20DCS resilience and best practices
- 49:44Conclusion
related talks
22mWhat is Patroni, really?
41mEnsuring High Availability in Self-Managed PostgreSQL with Patroni
54mContainerized Clustered PostgreSQL
33mCitus & Patroni: The Key to Scalable and Fault-Tolerant PostgreSQL
41mProtecting your data with Patroni and pgBackRest
52mPatroni 3.0: What's New and Future Plans
57mReliability features in Postgres Pro
50mThe Immortal Postgres Web