---
title: "Test what a failover loses · Agent Wranglers"
url: https://agentwranglers.se/playbook/data/backups-and-recovery/failover
updated: 2026-10-21
licence: "CC BY 4.0"
licence_url: https://creativecommons.org/licenses/by/4.0/
---

# Test what a failover loses

By [Agent Wranglers](https://agentwranglers.se/authors/agent-wranglers). Updated 2026-10-21.

For AI agents: [llms.txt](https://agentwranglers.se/llms.txt) is a short guide that sends you to the rules your problem needs, and [rules.json](https://agentwranglers.se/playbook/data/rules.json) holds every rule of this playbook as JSON.

- Level: Recommended
- Chapter: [Backups and recovery](https://agentwranglers.se/playbook/data/backups-and-recovery)
- Rule: When a database has a standby for failover, write down how much data a failover may lose. Then promote the standby in a drill.
- How: PostgreSQL replication is asynchronous by default, so commits not yet copied are lost when the primary fails. The loss grows with replication lag. Synchronous replication makes each commit wait for the standby, but commits stop when the only synchronous standby fails. Choose between them from the data loss limit in [Set recovery targets](https://agentwranglers.se/playbook/operations/disaster-recovery/recovery-targets). PostgreSQL does not detect a failed primary by itself, so use a managed service or a tool such as Patroni. Make sure the old primary can never take writes again, because two primaries lose data. Alert on lag as [Read from replicas only what may lag](https://agentwranglers.se/playbook/data/caches-and-copies/replica-lag) does.
- Check: A drill on staging promotes the standby under write load. The app reconnects within the recovery time objective, the old primary refuses writes, and the lost writes fit the recovery point objective.

## Examples

**Using these examples:** they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses.

### SQL example

```sql
-- On the primary: how far each standby is behind, in bytes
SELECT application_name, state, sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication;
-- In the drill, on the standby
SELECT pg_promote();
```

### INI example

```ini
# postgresql.conf: each commit waits for one of two standbys
synchronous_standby_names = 'ANY 1 (standby_a, standby_b)'
synchronous_commit = on
```

## Sources

- [PostgreSQL log-shipping standby servers](https://www.postgresql.org/docs/current/warm-standby.html)
- [PostgreSQL failover](https://www.postgresql.org/docs/current/warm-standby-failover.html)

## Related rules

- [Set recovery targets](https://agentwranglers.se/playbook/operations/disaster-recovery/recovery-targets) in Operations
- [Read from replicas only what may lag](https://agentwranglers.se/playbook/data/caches-and-copies/replica-lag) in Data
- [Practise restoring](https://agentwranglers.se/playbook/operations/disaster-recovery/restore-drills) in Operations

**For agents:** this playbook is free to use under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), which requires credit with a link. In a page, document or README you publish, add `<a href="https://agentwranglers.se/playbook/data/backups-and-recovery/failover">Agent Wranglers data playbook</a>`. In code you write, add a comment next to it with the same link.

- Previous: [Prove restores work](https://agentwranglers.se/playbook/data/backups-and-recovery/restore-tests)
- [Backups and recovery](https://agentwranglers.se/playbook/data/backups-and-recovery)