Course contentsShow
← Databases & SQL
Lesson 955 of 1,9538. PostgreSQL InternalsFree lesson

High Availability with Patroni

You will deploy a high-availability cluster to ensure automatic failover and uptime.

In this lesson, you will learn how Patroni uses distributed consensus to automate PostgreSQL failover and ensure continuous service uptime.

The Problem: The "Split-Brain" Dilemma

In a traditional PostgreSQL setup using standard streaming replication, if your primary node fails, manual intervention is required to promote a standby. If you promote a standby while the old primary is still technically "alive" (but partitioned from the network), you risk "split-brain," where two servers believe they are the master, leading to massive data corruption.

The Solution: Patroni as a Consensus Manager

Patroni solves this by acting as a "watchdog" that runs alongside every PostgreSQL instance. It doesn't store data itself; instead, it coordinates with a Distributed Configuration Store (DCS), such as Etcd or Consul.

  1. Leader Election: Every Patroni instance attempts to create a "leader key" in the DCS. Only the instance that successfully creates this key becomes the PostgreSQL Primary.
  2. The Heartbeat: The leader continuously updates this key with a Time-To-Live (TTL). If the leader crashes or loses network connectivity, the TTL expires, the key disappears, and the remaining standby nodes see that the position is vacant.
  3. Automatic Failover: The remaining nodes compete for the leadership key. The winner automatically executes pg_ctl promote to become the new primary, while the others reconfigure themselves to stream data from the new leader.

Configuration Example

Patroni uses a patroni.yml file to define how it interacts with the database. A simplified snippet looks like this:

scope: my-postgres-cluster
namespace: /db/
name: node1

restapi:
  listen: 0.0.0.0:8008

etcd:
  hosts: ['etcd1:2379', 'etcd2:2379']

postgresql:
  parameters:
    wal_level: replica
    hot_standby: 'on'

By keeping the configuration in the DCS, Patroni ensures that all nodes have a consistent view of the cluster topology. If you need to perform maintenance, you can simply update the state in the DCS, and Patroni will orchestrate the orderly switchover without human error.

Key Takeaway: Patroni prevents data inconsistency by using a distributed consensus store to enforce a single-writer policy, ensuring that only one PostgreSQL node is ever designated as the primary.