Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsPatroni coordinates PostgreSQL high availability: it uses a distributed configuration store (DCS) to track cluster leadership, manages streaming-replication roles, and helps a standby take over when the primary fails. It does not make every acknowledged write immune to loss. That depends on replication mode, which nodes remain reachable, and how the cluster behaves during failure and recovery.
The Patroni introduction and replication guide reviewed here are for version 4.1.5. The dynamic-configuration page is for 4.1.0, and the watchdog page is for 3.3.11. Defaults and behavior can differ by release, so verify them against the version you run.
How Patroni coordinates a PostgreSQL cluster
Patroni is a Python-based template for managing PostgreSQL high availability. PostgreSQL servers run on database nodes, while Patroni stores coordination information in a separate DCS. The documented DCS options include etcd, ZooKeeper, and Consul. The database nodes and DCS nodes are decoupled: a small database cluster does not mean the coordination service should also be a fragile two-node system. Patroni recommends three or five DCS nodes for consensus and fault tolerance. These are vendor recommendations, not independent benchmark results. Patroni introduction
Applications need a stable way to reach whichever PostgreSQL node is currently primary. Patroni’s introduction gives HAProxy configuration as one example of a single endpoint; the application should not rely on a fixed database host that may become a standby. Use a non-superuser database account for application connections so they do not consume connections reserved for Patroni’s database access. Patroni introduction
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute#1 Best Overall
What happens during failover
- Patroni instances use the DCS to coordinate which node holds leadership.
- If the primary fails, eligible standbys are considered for promotion according to their replication state and the cluster’s configuration.
- A promoted standby becomes the new primary. Applications must then be routed to it through the cluster’s endpoint or another service-discovery mechanism.
- The former primary must be reconciled with the new cluster history before it can safely rejoin. Depending on the divergence and configuration, that can involve rebuilding it or using
pg_rewind.
With only one primary and one standby, the cluster temporarily has no redundant standby after a failover until the failed node has rejoined or another standby has been provisioned. A successful promotion is therefore not the end of recovery work. Patroni introduction
Can Patroni lose data during failover?
Yes, depending on replication mode and failure scenario. PostgreSQL streaming replication is asynchronous by default. The primary can acknowledge a commit before the standby has received and replayed the corresponding WAL. If the primary then fails and a lagging standby is promoted, transactions acknowledged by the old primary but not present on the new one can be lost. Patroni introduction Patroni replication modes
Patroni’s maximum_lag_on_failover setting limits whether a follower that is too far behind is eligible for promotion. It is an eligibility threshold, not a zero-loss guarantee or a precise maximum for lost transactions: WAL position is not sampled continuously, so the measured lag may not capture every write made immediately before failure. Patroni replication modes
Rank #2
Choosing a replication mode
Replication mode is an operational trade-off between the conditions for acknowledging writes, write availability, and failover behavior. The table describes the documented distinctions; actual outcomes still depend on which nodes and network paths survive.
| Mode | Acknowledged writes after failover | Behavior when replicas or paths are unavailable | Operational trade-off |
|---|---|---|---|
| Asynchronous | A commit acknowledged by the former primary may be absent if the promoted standby had not received it. | Writes do not wait for a standby’s replication acknowledgement. | Typically avoids waiting on synchronous acknowledgements, but a lagging standby can mean lost acknowledged transactions after promotion. Patroni replication modes |
| Synchronous | Commit acknowledgement depends on synchronous replication state, but the mode is not an unconditional zero-data-loss warranty. | Patroni may adjust synchronous replication when no synchronous standby is eligible; the exact effective behavior depends on configuration and state. | Stronger durability conditions can add write latency and affect write availability. Simultaneous failures and cancellation while waiting for acknowledgement are among the documented caveats. Patroni replication modes |
| Strict synchronous | Uses synchronous acknowledgement conditions, with documented edge cases that prevent treating it as an absolute guarantee. | Patroni does not disable synchronous replication merely because no synchronous standby is eligible; writes can block until one is available. | Prioritizes the configured durability policy over write availability during loss of eligible synchronous replicas. Patroni replication modes |
| Quorum synchronous | Commit acknowledgement depends on the configured quorum of eligible replicas; promotion and quorum state must be considered together. | Other eligible standbys can satisfy the commit quorum when an individual replica is slow, subject to the quorum and node availability. | Can reduce the effect of one slow replica, but requires operators to understand which nodes are eligible voters and how quorum changes during failure. Patroni replication modes |
Asynchronous replication: prioritize write availability
Asynchronous replication is the default described in Patroni’s introduction. It lets the primary acknowledge writes without waiting for a standby, but a failover can expose a gap between acknowledged commits and the WAL available on the promoted node. A lag threshold can exclude a follower from promotion; it cannot recover changes that never reached a surviving node. Patroni introduction Patroni replication modes
Synchronous replication: add acknowledgement conditions
Patroni coordinates synchronous state through the DCS and PostgreSQL’s synchronous_standby_names. The number of synchronous nodes is configured with synchronous_node_count, whose documented default is 1; eligible-node availability can affect the effective count. Synchronous acknowledgement can increase write latency and constrain availability, and its behavior should be evaluated against the failure scenarios the system must tolerate. Patroni replication modes
Strict synchronous mode prevents Patroni from disabling synchronous replication when no synchronous standby is eligible. That policy can stop writes until a standby becomes available. It does not erase the guide’s caveats, including simultaneous failures and cancellation while waiting for a replication acknowledgement. Treat it as an explicit durability-versus-availability choice, not an unconditional promise of zero data loss. Patroni replication modes
Quorum synchronous replication: account for eligible voters
Quorum mode allows acknowledgements from a configured count of eligible nodes to satisfy the commit quorum, which can avoid letting one slow replica hold up every write. But quorum state is linked to the latest known primary and eligible voters, so a configuration that performs well during normal operation may behave differently as nodes fail or become ineligible. Evaluate promotion rules and quorum membership together rather than treating the acknowledgement count in isolation. Patroni replication modes
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Patroni’s replication guide recommends a three-node PostgreSQL data setup for write availability under one-host failure when using PostgreSQL synchronous replication. This is documented guidance, not a guarantee for every workload or topology; confirm that the chosen mode, number of eligible standbys, and failure assumptions match the service’s requirements. Patroni replication modes
How Patroni mitigates split brain
Split brain occurs when more than one PostgreSQL server accepts writes as primary. The resulting independent timelines can diverge, making recovery and data reconciliation difficult. Patroni attempts to stop PostgreSQL if a node cannot update its leader key in the DCS, helping prevent an isolated former primary from continuing to serve writes after it loses coordination. Patroni 3.3.11 watchdog support
A watchdog provides another safeguard. Patroni’s watchdog documentation says it is activated before PostgreSQL promotion; in required mode, a node refuses leadership if watchdog activation fails. If the watchdog’s keepalive expires, it resets the system. The page reviewed is for Patroni 3.3.11 and documents loop_wait=10, ttl=30, and watchdog expiry five seconds before TTL. Those are version-specific documented values, not defaults to assume for every installed release. Check the configuration and watchdog behavior for the release you operate. Patroni 3.3.11 watchdog support
Rejoining a former primary and scheduling a switchover
Rejoin after timelines diverge
After a failover, the former primary may have a history that diverges from the new leader. Patroni documents use_pg_rewind as a way to rejoin a former primary in this situation. For pg_rewind to work, data page checksums must have been enabled when the cluster was initialized or wal_log_hints must be set to on. These prerequisites need to be planned for before a failure, not added after the former primary has diverged. Patroni replication modes
Planned switchover
The REST API’s /switchover endpoint is intended for a healthy cluster that has a leader. A request can identify a candidate, or eligible nodes can participate in a leader race after the current leader steps down; the request can also be scheduled. This is a controlled transition, not the same operation as automatic failover in a degraded cluster. Patroni REST API
Release-specific dynamic configuration
Patroni’s dynamic configuration reference includes the failsafe_mode setting. Because the reviewed reference is for version 4.1.0, consult the documentation matching your installed release before depending on its precise behavior or changing its value. Patroni dynamic configuration, version 4.1.0
What to test before relying on failover
Configuration describes intended behavior; only failure testing can show whether the complete system meets its recovery and availability requirements. Patroni cautions that testing involves many variables: “Testing an HA solution is a time consuming process, with many variables.” Patroni introduction
- Replication and data loss: Test primary loss at different points relative to write acknowledgement. Verify which transactions are present after promotion for the selected replication mode.
- Eligibility and quorum: Take replicas and network paths out of service. Confirm which nodes remain eligible, whether writes proceed or block, and which node can be promoted.
- Split-brain safeguards: Exercise loss of DCS access and watchdog activation or keepalive failure in a controlled environment. Confirm that an isolated node cannot continue accepting writes as a second primary.
- Client routing: Observe how the application endpoint changes after promotion and whether clients reconnect to the new leader without continuing to send writes to a standby.
- Rejoin and recovery: Test recovery of a former primary, including the configured rewind or rebuild path, before depending on it to restore redundancy.
- Host and process stress: Include network behavior, disk I/O, file limits, RAM, CPU, virtualization contention, and process failures. Patroni notes that proper testing may require a trained system administrator or consultant. Patroni introduction
Run these tests against the PostgreSQL and Patroni releases, infrastructure, workload, and failure model that will actually be deployed. The documented mechanisms establish what Patroni is designed to coordinate; they do not replace verification that the whole service recovers safely.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
