Failover

Failover What happens to an application on prorm when the database moves underneath it, and what to configure so it survives. What actually happens A failover — a managed service promoting a standby, a proxy switching backends, a container restarting — breaks every open connection. In-flight queries fail. Pooled connections become stale but are not automatically discarded, so the first query on each one fails before the pool replaces it. So the visible symptom is a burst of connection errors lasting as long as the promotion, then recovery. If errors continue well past that, it is not the failover any more — go to Connection failures. Configure for it before it happens handleDisconnects lets the pool discard a dead connection rather than hand it out again. evict decides how often idle connections are checked, which bounds how long a stale one can linger. Retries with backoff cover the promotion window. A 60-second failover needs more than three attempts a second apart. Transactions do not survive it A transaction open across a failover is gone — the server that held it no longer exists. There is no way to resume it, and prorm will not retry it for you, because it cannot know whether the commit landed. Write for that: make the work idempotent, or record enough to determine afterwards whether it happened. Reads during a failover If reads go to replicas, a primary failover need not take reads down with it: Replicas lag. A read immediately after a write may not see it — route read-after-write to the primary. Afterwards 1. Confirm recovery with db.authenticate() rather than by watching logs. 2. Check for work that failed mid-transaction and needs replaying. 3. If errors outlasted the promotion, suspect the pool holding stale connections — verify handleDisconnects is on. Related reading Replication Connection pooling Transactions