Tair (Redis® OSS-Compatible):Descripción general de la alta disponibilidad

Causas

• Fallos en los hosts de la instancia

  Si Alibaba Cloud detecta que el host subyacente de una instancia presenta un fallo, como la terminación anómala de procesos o anomalías de memoria debido a una carga elevada, el sistema activa inmediatamente un cambio de nodo principal-réplica. Esta acción oportuna garantiza la restauración rápida de la instancia y minimiza la duración de cualquier interrupción causada por el fallo.

  Se le notifica sobre estos eventos mediante mensajes internos o correos electrónicos con el siguiente formato:

  [Alibaba Cloud] Estimado**: Se ha detectado una anomalía en su instancia r-bp1zxszhcgatnx** de Tair (nombre: ****). Se ha activado un cambio de nodo para garantizar el funcionamiento estable de la instancia. Le recomendamos comprobar si su aplicación sigue conectada a la instancia y configurarla para que se reconecte automáticamente.

• Riesgos ocultos en los hosts de la instancia

  Si Alibaba Cloud detecta riesgos en el host subyacente de una instancia, como inestabilidad en la red o anomalías en el disco, esto indica un posible impacto futuro en el funcionamiento normal de la instancia. En tales casos, el sistema inicia automáticamente tareas proactivas de operación y mantenimiento para gestionar los riesgos y activa un cambio de nodo principal-réplica durante la ventana de mantenimiento para reemplazar los nodos del host en riesgo.

  Sin embargo, para eventos que requieren una remediación urgente de riesgos, el sistema toma medidas rápidas para resolver los problemas e iniciar un cambio de nodo principal-réplica. Por ejemplo, si se identifica un bug crítico en la comunidad de Redis, la instancia correspondiente se somete proactivamente a una actualización de versión menor. Puede consultar los registros de estas acciones en el historial de eventos. Para obtener más información, consulte Query history events. También puede gestionar eventos pending de cambio de nodo principal-réplica. Para obtener más información, consulte View and manage scheduled events.

Impactos

La instancia completa automáticamente todo el proceso de cambio de nodo. Una vez finalizado el cambio, la instancia funciona según lo esperado.

No obstante, durante el proceso de cambio pueden presentarse las siguientes situaciones:

• Los nodos de datos donde se realiza el cambio de nodo se desconectan durante unos segundos y pueden permanecer en modo de solo lectura hasta por 30 segundos.

• Después de que la instancia entra en el estado Switching, no es posible gestionarla. Por ejemplo, no puede modificar las configuraciones de la instancia ni migrarla a otra zona. Cuando finaliza el cambio de nodo principal-réplica, el estado de la instancia cambia a Running.

Acciones recomendadas

• Asegúrese de que su aplicación esté configurada para reconectarse automáticamente a la instancia o para manejar excepciones. De lo contrario, podrían devolverse los siguientes mensajes de error durante un cambio de nodo: READONLY You can't write against a read only instance o DISABLE You can't write or read against a disable instance.

• Cuando se activa un cambio de nodo principal-réplica para una instancia, esta completa automáticamente todo el proceso al promover el nodo réplica como nuevo nodo principal y crear otro nodo réplica para la sincronización de datos entre los nodos principal y réplica. No necesita realizar ninguna operación durante este proceso.

  Nota

  Una vez completado el cambio de nodo principal-réplica en una instancia de doble zona, el nodo principal reside en la zona secundaria y el nodo réplica en la zona primaria. Esto podría provocar acceso entre zonas entre la instancia y otros servicios. Para resolver este problema, cambie manualmente de zona en la página Service availability de la consola.

Temas relacionados

Tair (Redis OSS-compatible) también admite cambios manuales de nodo principal-réplica. Esta función resulta útil para simulacros de recuperación ante desastres o para conectarse al nodo más cercano en implementaciones con múltiples zonas de disponibilidad. Para obtener más información, consulte Manually perform a master-replica switchover.

Preguntas frecuentes

• ¿Cuál es el principio detrás del cambio de nodo principal-réplica activado por un fallo en la instancia?

  El sistema de alta disponibilidad confía en su mecanismo de detección de actividad para identificar fallos. La siguiente tabla describe dicho mecanismo.

  Evento principal	Descripción
  Comprobación de estado	El sistema de alta disponibilidad comprueba si los nodos principal y réplica están en buen estado.
  Fallo del nodo principal	Cuando se determina que un nodo principal no está available, un nodo réplica actúa como nodo principal. Al mismo tiempo, se utiliza la dirección IP virtual (VIP) del nodo réplica, pero el endpoint de la instancia permanece sin cambios. Se crea otro nodo réplica para garantizar la sincronización de datos.
  Fallo del nodo réplica	Cuando se determina que un nodo réplica no está available, se crea automáticamente otro nodo réplica para garantizar la sincronización de datos y mantener la persistencia de datos de la arquitectura principal-réplica.

  Nota

  Es posible que se pierdan datos específicos escritos recientemente en un nodo principal, ya que la sincronización entre los nodos principal y réplica se implementa de forma asíncrona.

• P: ¿Cómo puedo consultar mi historial de cambios de nodo principal-réplica (HA)?

  R:

  1. Vaya al Event Center en la consola y seleccione una región en la parte superior de la página.

  2. Haga clic en Abnormal Events.

  3. Seleccione el rango de tiempo deseado.

  4. Establezca Archive Status en All para consultar los registros de instance failover y sus causas, como Master unavailable.

• P: Si ocurre un cambio de nodo principal-réplica en una instancia con división de lectura/escritura, ¿se ven afectados los read replicas?

  R: Durante el cambio de nodo, las réplicas de lectura available disminuyen temporalmente en una y vuelven a la normalidad al finalizar.

• P: En una instancia cluster architecture, ¿afecta el cambio de nodo de un shard de datos a toda la instancia?

  R: No. Solo se ve afectado el shard de datos correspondiente.