Descripción general de la configuración de alta disponibilidad

En esta página, se brinda una descripción general de la configuración de alta disponibilidad (HA) para las instancias de Cloud SQL. A fin de configurar una instancia nueva para HA, o a modo de habilitar HA en una instancia existente, consulta la sección sobre habilitar o inhabilitar la alta disponibilidad en una instancia.

Descripción general de la configuración de HA

La configuración de HA, a veces llamada clúster, proporciona redundancia de datos. Una instancia de Cloud SQL configurada para HA también se llama instancia regional y se la ubica en una zona primaria y secundaria dentro de la región configurada. Dentro de una instancia regional, la configuración se compone de una instancia primaria y una instancia en espera. A través de la replicación síncrona a los discos persistentes de cada zona, todas las operaciones de escritura realizadas en la instancia principal también se realizan en la instancia de espera. En el caso de fallas en una instancia o zona, esta configuración reduce el tiempo de inactividad y tus datos siguen disponibles para aplicaciones cliente.

Nota: La instancia en espera no se puede usar para solicitudes de lectura. Esto difiere de la configuración de HA heredada de Cloud SQL para MySQL.

La asistencia para el PD regional de Cloud SQL y la configuración de HA de Cloud SQL tienen disponibilidad general (GA) con cobertura completa del ANS. Una instancia configurada con HA se cobra el doble del precio que una instancia independiente. Esto incluye CPU, RAM y almacenamiento. A fin de obtener más información, consulta la página de Precios de Cloud SQL para MySQL.

Descripción general del diagrama de la configuración de HA de Cloud SQL. Descrito en el texto de abajo.

Descripción general de la conmutación por error

Si una instancia configurada con HA deja de responder, de modo automático, Cloud SQL cambia y entrega los datos desde la instancia independiente. A esto se lo llama conmutación por error. Para ver si ocurrió una conmutación por error, revisa la historia de conmutación por error de tu registro de operaciones.

Haz clic en las pestañas para ver cómo la conmutación por error afecta a tu instancia.

Normal

Diagrama de una instancia en buen estado antes de una conmutación por error

Conmutación por error

Diagrama de la instancia cuando se produce una conmutación por error

Conmutación por recuperación

Diagrama de la instancia después de la conmutación por recuperación

Proceso

El proceso siguiente ocurre de esta manera:

  • Falla la instancia principal o la zona.

    Cada segundo, la instancia principal escribe en un sistema de base de datos como una señal de monitoreo de funcionamiento. Si no se detectan varias señales de monitoreo por funcionamiento, se inicia la conmutación por error. Esto sucede si la instancia principal no responde durante 60 segundos aproximados, o si la zona que contiene la instancia principal experimenta una interrupción.

  • Ahora, la instancia independiente entrega los datos hasta la reconexión.

    A través de una dirección IP estática compartida con la instancia principal, la instancia independiente, ahora, entrega los datos desde la zona secundaria.

Requisitos

Para que Cloud SQL permita una conmutación por error, la configuración debe cumplir con estos requisitos:

  • La instancia principal debe estar en un estado operativo normal (no detenido, en mantenimiento o en medio de una operación de larga duración).
  • La zona secundaria y la instancia en espera deben estar en buen estado. Cuando la instancia en espera no responde o se interrumpe la replicación en la zona secundaria, se bloquean las operaciones de conmutación por error. Después de que Cloud SQL repara la instancia en espera y la zona secundaria está disponible, la replicación se reanuda y Cloud SQL permite la conmutación por error.

Copia de seguridad y restablecimiento

Las copias de seguridad automáticas y la recuperación de un momento determinado deben estar habilitadas para la alta disponibilidad (la recuperación de un momento determinado usa el registro binario).

Instancias y aplicaciones

No existe ninguna diferencia en trabajar con instancias con o sin HA, por lo que tu aplicación no necesita estar configurada de ningún modo en particular. Cuando ocurre la conmutación por error, cualquier conexión existente a la instancia principal y a las réplicas de lectura se encuentra cerrada y tardará entre 2 y 3 minutos para que se restablezcan las conexiones. Tu aplicación se reconecta con la misma string de conexión o dirección IP, por lo tanto, no necesitas actualizar tu aplicación después de una conmutación por error.

Para ver con exactitud cómo la conmutación por error afecta tus aplicaciones, inicia la conmutación por error de forma manual.

Tiempo de inactividad por mantenimiento

Los eventos de mantenimiento afectan a las instancias principales configuradas con HA de la misma manera que cualquier otra instancia. Es posible que las instancias principales estén inactivas durante este tiempo. A fin de minimizar el impacto en el servicio, puedes establecer un período de mantenimiento para controlar cuándo se produce el tiempo de inactividad.

Cuando se lleva a cabo el mantenimiento de una instancia, no se realiza una conmutación por error a la instancia en espera. Las actualizaciones de mantenimiento se aplican a la instancia en espera al mismo tiempo que a la instancia principal.

Rendimiento

El rendimiento del disco persistente regional depende de muchos factores. En particular, observa el tamaño del tipo de instancia de VM, y la entrada y salida de tu carga de trabajo. Otra métrica que debes tener en cuenta es que la latencia del disco persistente regional que tiene unidades de estado sólido (SSD) es superior a la de un disco persistente que tiene un SSD local. Esto significa que, si tu carga de trabajo no es una carga de trabajo de transmisión y no es sensible a la latencia, no puede alcanzar el límite de operaciones de entrada y salida por segundo (IOPS) porque el disco persistente regional con SSD tiene una latencia mayor que un disco persistente con SSD local. Esto se debe a que la redundancia necesaria para escribir dos copias aumenta la latencia final.

Opción heredada de alta disponibilidad de MySQL

Hasta el primer trimestre de 2021, tienes la opción de usar el proceso heredado para agregar alta disponibilidad a las instancias de MySQL, en el que se usa una réplica de conmutación por error. La funcionalidad heredada no está disponible en Cloud Console. En su lugar, usa los comandos gcloud o cURL. Consulta Crear una nueva instancia configurada para alta disponibilidad o Configurar una instancia existente para alta disponibilidad .

Próximos pasos