ApsaraDB RDS:Manage primary/secondary switchover

Requisitos previos

• Si la instancia es una instancia estándar, debe pertenecer a una de las siguientes ediciones:

  • Serie de alta disponibilidad

  • RDS Enterprise Edition

  • Cluster Edition

  Nota

  Las instancias de la serie básica no cuentan con un nodo secundario, por lo que no admiten el cambio entre nodos principal y secundario.

• Si la instancia es de solo lectura, debe pertenecer a la serie de alta disponibilidad y utilizar la clase de almacenamiento en disco en la nube.

Contexto

• Cambio automático: Esta función está habilitada de forma predeterminada. Si el nodo principal falla, RDS transfiere automáticamente las cargas de trabajo al nodo secundario. Para obtener más información sobre los eventos que desencadenan un cambio entre nodos principal y secundario, consulte Reasons for primary/secondary switchover.

• Cambio manual: Aunque el cambio automático esté habilitado, puede ejecutar manualmente un cambio entre nodos principal y secundario. El cambio manual resulta útil para simulacros de recuperación ante desastres o para escenarios como la conexión desde la zona más cercana en un despliegue multizona.

Para obtener información sobre el cambio entre nodos principal y secundario en otros motores de base de datos, consulte los siguientes temas:

• SQL Server primary/secondary switchover

• PostgreSQL automatic or manual primary/secondary switchover

• MariaDB primary/secondary switchover

Impacto

• Un cambio entre nodos principal y secundario provoca una interrupción del servicio que generalmente dura 15 segundos o menos. Asegúrese de que su aplicación cuente con un mecanismo de reconexión automática.

  Si su aplicación utiliza una versión anterior del componente Druid para la gestión de conexiones a la base de datos, es posible que no se reconecte automáticamente tras una desconexión. Para evitar este problema, actualice el componente Druid a la versión 1.1.16 o posterior.

• Si la instancia principal tiene instancias de solo lectura asociadas, estas pueden experimentar un retraso de datos de varios minutos después del cambio. Esto se debe a que RDS debe reconstruir la tarea de replicación y sincronizar los datos incrementales.

• El cambio entre nodos principal y secundario no modifica el endpoint de la instancia, pero la dirección IP subyacente podría cambiar. Se recomienda utilizar el endpoint para garantizar que la aplicación continúe ejecutándose correctamente durante el cambio.

• Si la instancia experimenta un fallo grave, el cambio puede tardar más de lo habitual.

Cambio manual entre nodos principal y secundario

1. Vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside la instancia de RDS. A continuación, localice la instancia de RDS y haga clic en su ID.

2. En el panel de navegación izquierdo, haga clic en Service Availability.

3. En la sección Availability Information, haga clic en Switch Primary/Secondary Instance.

4. Seleccione una hora para el cambio y haga clic en Confirm.

   Importante

   Durante un cambio entre nodos principal y secundario, no es posible realizar operaciones como gestionar bases de datos y cuentas, o cambiar el tipo de red. Se recomienda seleccionar Switch immediately using current settings.

   Para instancias de Cluster Edition, también puede ejecutar un cambio entre nodos principal y secundario desde el diagrama de topología de la instancia en la página Basic Information.

Deshabilitar temporalmente el cambio automático entre nodos principal y secundario

El cambio automático está habilitado de forma predeterminada. Cuando el nodo principal falla, RDS cambia automáticamente al nodo secundario. Puede deshabilitar temporalmente el cambio automático en los siguientes escenarios:

• Para evitar cualquier impacto en la disponibilidad del sistema durante promociones de ventas importantes.

• Para evitar que un cambio introduzca variables inesperadas durante actualizaciones críticas de aplicaciones.

• Durante eventos importantes o periodos de garantía de estabilidad, cuando no desea que un cambio entre nodos principal y secundario afecte la estabilidad del sistema.

1. Vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside la instancia de RDS. A continuación, localice la instancia de RDS y haga clic en su ID.

2. En el panel de navegación izquierdo, haga clic en Service Availability.

3. En la sección Availability Information, haga clic en Automatic Primary/Secondary Switchover.

   Nota

   Si el botón Automatic Primary/Secondary Switchover no se muestra, compruebe que su instancia cumple con los requisitos previos descritos en este tema.

4. Seleccione Temporarily Disable, establezca la hora en Disable Until y luego haga clic en Confirm.

   Nota

   • El cambio automático entre nodos principal y secundario se vuelve a habilitar automáticamente después de la hora especificada en Disable Until.

   • El periodo de deshabilitación predeterminado es de un día. Puede establecer un periodo de deshabilitación de hasta siete días. El periodo finaliza a las 23:59:59 del último día.

Una vez completada la configuración, puede consultar la fecha de vencimiento de la deshabilitación temporal en la página Service Availability.

Consulta de registros de cambio entre nodos principal y secundario

1. Vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside la instancia de RDS. A continuación, localice la instancia de RDS y haga clic en su ID.

2. En el panel de navegación izquierdo, haga clic en Service Availability.

3. En la sección Primary/Secondary Switchover Logs, especifique un rango de tiempo para consultar los registros.

   

Preguntas frecuentes

• P: ¿Es posible acceder al nodo secundario?

  R: Solo es posible acceder a los nodos secundarios de instancias de Cluster Edition. Los nodos secundarios de otras ediciones de instancias no son accesibles.

• P: Después de un cambio entre nodos principal y secundario, ¿es necesario volver manualmente al nodo principal original?

  R: No. Los datos en los nodos principal y secundario están completamente sincronizados. Después del cambio, el antiguo nodo secundario se convierte en el nuevo nodo principal. No se requiere ninguna acción adicional.

• P: Tras un cambio entre nodos principal y secundario, el estado de la instancia no ha vuelto a Running después de más de 10 minutos. ¿Cuáles son las posibles causas y cómo resolver el problema?

  Cuando un evento anómalo desencadena un cambio de alta disponibilidad (HA) en RDS, es posible que las conexiones persistentes de la aplicación no detecten los cambios en el estado de la conexión. Si no configura un valor de tiempo de espera del socket, la aplicación esperará indefinidamente a que la base de datos devuelva un resultado, y generalmente agotará el tiempo de espera después de varios cientos de segundos. Durante este periodo, algunas conexiones a la base de datos dejan de estar disponibles y las sentencias SQL fallan con frecuencia. Para evitar conexiones no válidas, se recomienda configurar connectTimeout y socketTimeout para prevenir esperas indefinidas durante errores de red y así reducir el tiempo de inactividad.

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

API relacionadas