Conmutación por error entre instancias principal y secundaria - ApsaraDB RDS

Este tema describe cómo conmutar las cargas de trabajo entre las instancias principal y secundaria de ApsaraDB RDS for MariaDB. Puede habilitar la conmutación automática entre instancias principal y secundaria para su sistema de base de datos. De este modo, si la instancia principal de RDS falla, el sistema transfiere automáticamente las cargas de trabajo a la instancia secundaria de RDS. Tras la conmutación, la instancia secundaria se promueve como la nueva instancia principal de RDS y el endpoint utilizado para conectarse al sistema de base de datos permanece sin cambios. Su aplicación puede usar dicho endpoint para conectarse a la nueva instancia principal de RDS. Las conmutaciones automáticas entre instancias principal y secundaria garantizan la alta disponibilidad. También puede conmutar manualmente las cargas de trabajo entre las instancias principal y secundaria de RDS.

Si utiliza RDS High-availability Edition, se proporciona una instancia secundaria de RDS como reserva de la instancia principal de RDS de su sistema de base de datos. Los datos de la instancia principal de RDS se sincronizan en tiempo real con la instancia secundaria de RDS. Solo puede acceder a la instancia principal de RDS; no es posible acceder a la instancia secundaria de RDS.

Si la instancia principal de RDS falla, sus cargas de trabajo se conmutan automáticamente a la instancia secundaria de RDS.

Notas de uso

Durante una conmutación, su servicio podría interrumpirse. Asegúrese de que su aplicación esté configurada para reconectarse automáticamente a la instancia.

Procedimiento

Inicie sesión en la consola de ApsaraDB RDS.
En la barra de navegación superior, seleccione la región donde reside la instancia de RDS.
Localice la instancia de RDS y haga clic en el ID de la instancia.
En el panel de navegación izquierdo, haga clic en Service Availability.
En la sección Availability Information, haga clic en Switch Primary/Secondary Instance.
Seleccione un horario de conmutación y haga clic en Ok.

Durante una conmutación entre instancias principal y secundaria, no es posible realizar diversas operaciones. Por ejemplo, no puede gestionar bases de datos ni cuentas, o cambiar el tipo de red. Se recomienda realizar la conmutación durante la ventana de mantenimiento programado.
Nota
Si desea modificar la ventana de mantenimiento, realice a continuación las operaciones:
1. Haga clic en modify.
2. En la sección Configuration Information, modifique la ventana de mantenimiento y haga clic en Save.
3. Vaya a la página Service Availability, actualice la página y continúe con el procedimiento.

Preguntas frecuentes

¿Es necesario conmutar manualmente las cargas de trabajo de la instancia secundaria de RDS a la instancia principal de RDS después de una conmutación entre instancias principal y secundaria?

No, no es necesario conmutar manualmente las cargas de trabajo de la instancia secundaria de RDS a la instancia principal de RDS tras una conmutación. Los datos en la instancia principal de RDS son idénticos a los de la instancia secundaria de RDS. Después de la conmutación, la instancia secundaria de RDS funciona como la nueva instancia principal de RDS. No se requieren operaciones adicionales.
Cada vez que se realiza una conmutación entre instancias principal y secundaria, mi instancia de RDS no se ejecuta correctamente durante 10 minutos después de completar la conmutación. ¿Cuáles son las posibles causas? ¿Cómo puedo solucionar este problema?

R: Cuando una excepción desencadena una conmutación por alta disponibilidad, es posible que las conexiones persistentes de su aplicación no detecten el cambio en el estado de la conexión. Si no se configura un tiempo de espera de socket, la aplicación espera indefinidamente una respuesta de la base de datos y suele desconectarse solo después de cientos de segundos. Durante este periodo, algunas conexiones a la base de datos no funcionan correctamente, lo que provoca fallos en numerosas consultas SQL. Para evitar estas conexiones inválidas y reducir el tiempo de recuperación, se recomienda configurar los parámetros connectTimeout y socketTimeout. Esto evita que la aplicación espere indefinidamente durante un error de red.

Establezca los valores de tiempo de espera según su carga de trabajo y patrones de uso específicos. Para escenarios de procesamiento de transacciones en línea (OLTP), se recomienda como punto de partida establecer connectTimeout en 1–2 segundos y socketTimeout en 60–90 segundos. Estos valores son solo de referencia.