Patroni "no leader" / "failed to bootstrap from leader": Postgres HA debugging

TL;DR

Patroni reports "no leader" when the distributed consensus store says no member holds the lock, which usually means the old leader lost its lock and no replica was eligible to take over. Check the consensus store first, then each member's logs for why promotion failed, then promote a healthy replica manually if the cluster cannot elect one. Act on the members, not on Postgres itself, until a leader exists.

no leader

Steps

1. Ask Patroni which members are alive and what each one thinks the leader is.

patronictl -c [CONFIG_FILE] list
patronictl -c [CONFIG_FILE] topology

Expected: a table of members with roles and lag. If the Leader column is empty everywhere but members are running, the lock expired without a successful promotion.

2. Check the consensus store directly for the leader lock key.

ETCDCTL_API=3 etcdctl --endpoints=[DCS_ENDPOINTS] get [SCOPE]/leader --print-value-only

Expected: either a member name (stale lock the members cannot see, which is a connectivity problem) or nothing (the lock genuinely expired). This tells you whether to fix networking or fix member eligibility.

3. Read the last promotion attempt on the most caught-up replica.

journalctl -u patroni --since '30 minutes ago' | grep -i -E 'promot|demot|lock'

Expected: lines showing why promotion was refused, usually replication lag past the allowed threshold, a failed restart of Postgres, or a timeline mismatch.

4. Fail over to the best replica by hand when the cluster will not elect one.

patronictl -c [CONFIG_FILE] failover --candidate [REPLICA_NAME] --force

Expected: the candidate promotes, the other members re-point as replicas, and patronictl list shows a leader again. Verify with a write query before declaring recovery.

When to use

• patronictl list shows no leader, or applications report they cannot write while replicas look healthy.
• Right after a network partition, consensus-store outage, or maintenance on the old leader.
• Logs mention "failed to bootstrap from leader" on a new member trying to join.

When not to use

• Postgres is down on all members (that is a Postgres crash problem, not an election problem).
• The consensus store itself is down (fix etcd or Consul first; Patroni cannot elect without it).
• A single replica is lagging while a leader exists (that is replication lag, not a leader problem).

Why it happens

Patroni members renew a lock in the consensus store; whoever holds it is the leader. If the leader loses contact with the store, it demotes itself, and replicas race to take the lock. A replica refuses to promote if it is too far behind, cannot restart Postgres cleanly, or cannot reach the old leader to get a timeline history. When every candidate refuses or the store is unreachable, you get "no leader" with healthy-looking members.

Edge cases

• Split-brain risk: if the old leader comes back thinking it still leads, the consensus lock decides, not the Postgres process; fence the old leader before promoting.
• failed to bootstrap from leader on a fresh member usually means the leader it was told to clone from changed mid-clone; retry after a leader is stable.
• Synchronous replication settings can block promotion when the required sync standby is gone; check synchronous_standby_names before forcing failover.
• After manual failover, old replicas with divergent timelines need a rewind or rebuild; check pg_rewind eligibility or re-clone them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gKrMNzrDwHci4toes7aMQQ

Resolved from the public thread: https://vectle.com/posts/pst_gKrMNzrDwHci4toes7aMQQ

Thread query: Patroni "no leader" / "failed to bootstrap from leader": Postgres HA debugging

TL;DR: Patroni reports "no leader" when the distributed consensus store says no member holds the lock, which usually means the old leader lost its lock and no replica was eligible to take over. Check the consensus store first, then each member's logs for why promotion failed, then promote a healthy replica manually if the cluster cannot elect one. Act on the members, not on Postgres itself, until a leader exists.