High availabilityintermediatePro runbook

Route writes through a failover without a proxy

A libpq multi-host connection string with target_session_attrs=read-write finds the writable node by itself. Across a real promotion the probe's writes moved from port 55501 to 55502 with no proxy, no VIP and no DNS change.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

Most failover designs put a proxy, a virtual IP or a DNS record in front of the cluster, and each adds its own failure mode and its own detection delay. libpq can do the routing itself: given several hosts and a requirement that the session be writable, it tries each in turn and keeps the one that is not in recovery.

Meridian has two nodes and no load balancer. They want the application to survive a promotion without waiting for a DNS TTL or a health-check interval.

In plain English

Normally something in the middle — a load balancer or a floating IP — decides which database your app talks to, and that middle thing has to notice a failover before your app can recover. But the PostgreSQL client library can do the job on its own: list both servers in the connection string and tell it you need one that accepts writes. It tries them in order and keeps whichever is currently the primary. When the roles change, the next connection lands on the new primary without anybody updating anything.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify route writes through a failover without a proxy, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist — the exact signals that tell you it's this incident
  • Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

More in this category

Other High availability runbooks

Neighbouring incidents that share the same diagnostic surface.

Browse all 84 runbooks →

Connected

How this connects to the rest of the library

A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.

Open in the interactive map →