Automatisches Postgres-Failover, selbst gehostet

Die meisten „self-hosted Postgres”-Setups sind in Wirklichkeit einfach Postgres auf einem Server. Wenn dieser Server ausfällt, fällt auch deine Datenbank aus, und Recovery bedeutet, dein letztes Backup zu suchen und zu hoffen, dass es aktuell genug ist. Für ein Nebenprojekt ist das in Ordnung. Sobald ein Datenbankausfall bedeutet, dass dein Produkt down ist, ist es das nicht mehr.

Railyard behandelt das als Plattform-Problem, nicht als etwas, das jedes Team selbst mit Patroni, repmgr oder einem handgeschriebenen Skript verkabeln muss, das pg_stat_replication beobachtet und betet.

Was ein Datenbankserver wirklich ist

Ein Datenbankserver ist einer deiner eigenen Server — ein DigitalOcean Droplet, eine Hetzner-Box, was auch immer du angebunden hast — der Daten hält und sonst nichts. Er bekommt keinen Web-Proxy, keine Build-Tools, und keine App wird je auf ihn deployt. Seine Ports sind nur für die App-Server geöffnet, die ihn tatsächlich nutzen.

Füge beim Erstellen einen Standby hinzu (Pro- und Team-Pläne), und Railyard hält eine live, kontinuierlich nachfolgende Kopie von Postgres, MySQL und Redis auf einem zweiten Server. Du konfigurierst die Replikation nicht selbst; sie kommt automatisch hoch, sobald beide Server online sind.

Was passiert, wenn der Primary ausfällt

Railyard prüft jeden Standby alle 5 Minuten und zeigt dir, wie weit er zurückliegt. Wenn ein Datenbankserver 3 Minuten lang nicht mehr antwortet und sein Standby unabhängig davon ebenfalls den Kontakt zu ihm verloren hat — eine bewusste zweiseitige Prüfung, damit ein eigener Netzwerk-Hickser des Standbys keine falsche Beförderung auslöst — übernimmt der Standby:

1. Er beginnt, die Daten auf den üblichen Ports zu servieren.
2. Jede App, die diesen Datenbankserver nutzt, wird automatisch gegen ihn neu deployt.
3. Point-in-Time-Recovery wird dort wieder eingeschaltet.
4. Du bekommst eine Benachrichtigung, die genau auflistet, was sich verschoben hat.

Niemand muss sich um 3 Uhr nachts per SSH einloggen und pg_promote() ausführen. Wenn du die Entscheidung lieber selbst triffst — der Primary ist noch teilweise erreichbar und du vertraust einem automatischen Cutover noch nicht —, macht Promote by hand die gleiche Übernahme auf Abruf, von der Seite jedes der beiden Server aus.

Was den Cutover nicht überlebt

Ehrlich damit umzugehen ist wichtiger als das Feature selbst. Writes, die der alte Primary in seinen letzten Sekunden vor dem Ausfall entgegengenommen hat, können verloren gehen — das ist der echte Tradeoff asynchroner Replikation, und es ist derselbe Tradeoff, den jede Managed-Postgres-Lösung mit Standby eingeht, Railyard eingeschlossen. Elasticsearch und ein dediziertes App-eigenes Redis werden nicht repliziert, sie starten also leer auf dem neuen Primary (Apps indizieren Elasticsearch nach ihrem Redeploy automatisch neu; ein sich selbst neu aufbauender Cache ist für Nutzer normalerweise unsichtbar).

Wenn der alte Server wieder online kommt, zeigt seine Dashboard-Seite unmissverständlich an, dass er ersetzt wurde und dass nichts seine jetzt veralteten Daten nutzt. Make it the new standby kopiert frische Daten vom neuen Primary, sodass auch der nächste Ausfall abgedeckt ist — das Paar repariert sich selbst, statt stillschweigend ungeschützt zu laufen, bis es jemand merkt.

Warum das anders ist als „nimm einfach RDS”

Es ist kein Ersatz für eine Managed-Datenbank, wenn du eigentlich das ganze Problem an AWS abgeben willst — Railyard unterstützt auch das, du kannst eine App direkt auf eine externe RDS-, ElastiCache- oder Elastic-Cloud-URL zeigen lassen. Der Unterschied gilt für den weit häufigeren Fall: eine Postgres-Datenbank, die auf einem Server läuft, den du besitzt, bepreist mit dem, was dieser Server tatsächlich kostet, die aber trotzdem failover-fähig ist wie die Managed-Version. Teams, die von Heroku Postgres wegziehen, stoßen genau auf diese Lücke — Herokus Managed-Failover verschwindet in dem Moment, in dem du gehst, und die meisten Self-Hosted-Setups ersetzen es nie.

Standardmäßig geschützt heißt auch standardmäßig gesichert: Jede App-Datenbank auf einem Datenbankserver bekommt ein tägliches Backup, und jedes wird durch eine tatsächliche Wiederherstellung geprüft, nicht nur als gut angenommen. Siehe Datenbankserver für das Gesamtbild, einschließlich Connection Pooling und Postgres-Upgrades, Autoscaling und Failover dafür, wie das mit App-Level-Failover zusammenpasst, oder Datenbankserver vs. Datenbank-Addon dafür, wann genau dieser Schutz greift im Vergleich zum günstigeren Standard.