Wie machst du eine managed relationale Datenbank hochverfügbar?

Betreib sie Multi-AZ, dann gibt es ein synchrones Standby in einer anderen Zone und der Failover läuft automatisch, typischerweise innerhalb von ein bis zwei Minuten. Read Replicas sind für Read-Skalierung da, nicht für Verfügbarkeit, denn die Replikation ist asynchron und kann hinterherhinken. Untermauer das mit automatischen Backups und Point-in-time Recovery, verbinde dich über den Cluster-Endpoint oder einen Proxy, damit der Failover abgefangen wird, und teste den Failover wirklich, statt ihm zu vertrauen.

Multi-AZ ist der Kern: ein synchrones Standby in einer zweiten Zone, und der Managed Service promoted es, wenn das Primary ausfällt, meist innerhalb von ein bis zwei Minuten. Die Unterscheidung, die ich immer explizit mache: eine Read Replica ist kein Failover-Ziel, sie ist asynchron, eine Promotion kann also heißen, dass du jüngste Writes verlierst. Sie ist für Read-Skalierung da. Haltbarkeit ist nochmal etwas anderes, also automatische Backups plus Point-in-time Recovery, und ich kopiere die in eine andere Region, denn eine hochverfügbare Datenbank, die nur in einer Region existiert, ist trotzdem einen schlechten Tag von weg entfernt. Was Leute vergessen, ist die Anwendung. Der Failover ändert, auf welchen Host der Endpoint zeigt, ein Connection Pool mit abgestandenen Verbindungen oder eine Runtime, die DNS ewig cached, scheitert also weiter, wenn die Datenbank längst wieder gesund ist. Deshalb verbinde ich über den Cluster-Endpoint oder einen Proxy, setze sinnvolle Pool-Validierung und stelle sicher, dass Retries sicher sind. Und ich teste es, indem ich in einer niedrigeren Umgebung einen Failover auslöse und messe, wie lange die Anwendung zur Erholung braucht, denn diese Zahl ist immer schlechter als die beworbene.