¿Cómo haces que una base de datos relacional gestionada sea de alta disponibilidad?

Ejecútala en varias zonas de disponibilidad, para que haya un standby síncrono en otra zona y el failover sea automático, normalmente en uno o dos minutos. Las réplicas de lectura son para escalar lecturas, no para disponibilidad, porque la replicación es asíncrona y puede ir con retraso. Respáldalo con copias automáticas y recuperación a un punto en el tiempo, conecta a través del endpoint del clúster o de un proxy para que el failover se gestione, y prueba el failover de verdad en vez de fiarte.

El núcleo es el despliegue en varias zonas de disponibilidad: un standby síncrono en una segunda zona, y el servicio gestionado lo promociona si el primario falla, normalmente en menos de uno o dos minutos. La distinción que siempre hago explícita es que una réplica de lectura no es un destino de failover, es asíncrona, así que promocionar una puede significar perder escrituras recientes; está ahí para escalar lecturas. La durabilidad es otra cosa aparte, así que copias automáticas más recuperación a un punto en el tiempo, y esas las copio a otra región porque una base de datos de alta disponibilidad que solo existe en una región sigue estando a un mal día de desaparecer. La parte que la gente olvida es la aplicación. El failover cambia a qué host apunta el endpoint, así que un pool de conexiones con conexiones obsoletas o un runtime que cachea DNS para siempre seguirá fallando después de que la base de datos vuelva a estar sana. Por eso conecto a través del endpoint del clúster o de un proxy, configuro una validación razonable del pool y me aseguro de que los reintentos son seguros. Y lo pruebo, disparando un failover en un entorno inferior y cronometrando cuánto tarda la aplicación en recuperarse, porque ese número siempre es peor que el anunciado.