Quorum-Based Consistency for Cluster Changes with CloudNativePG Operator
summary
CloudNativePG adds a failoverQuorum CRD (since v1.28) that maps Postgres’ synchronous_standby_names into three values N (target set), W (required standbys) and R (promotable intersection) and enforces the check R+W > N before automatic promotions. The instance manager writes a JSON metadata blob and a config hash into custom.conf, SIGHUPs Postgres and waits for the hash to reappear to prove the reload, logs isStronglyConsistent true on success, and disables auto‑failover for unsafe cases requiring manual intervention.
AI-written summary · about
chapters (14)
- 0:00Music & introduction
- 0:28Running Postgres on Kubernetes
- 1:25Why cluster management is external
- 2:39Replication flexibility and trade-offs
- 3:45Synchronous replication explained
- 6:33Key Postgres replication parameters
- 10:06Tuning durability, availability, performance
- 12:34The failover correctness problem
- 13:54Quorum-based failover design explained
- 16:04Walking through failover scenarios
- 19:11Introducing failoverquorum in CNPG
- 22:00Ensuring config consistency with hashing
- 25:02Real-world failover decision examples
- 27:45Wrap-up and community contribution call
related talks
05mFive Minutes by CloudNativePG River
24mAre NoSQL databases more reliable?
41mCloud-Native Databases in Kubernetes with OpenShift and Postgres
34mRun PostgreSQL:The Kubernetes way
57mReliability features in Postgres Pro
36mKube-native Postgres [I]
30mRunning PostgreSQL on Kubernetes in Production: Day 2 Operations with CloudNativePG
55mHigh Availability with PostgreSQL and Pacemaker