Compartir a través de

Alta disponibilidad en Azure Database for MySQL

Al utilizar Azure Database for MySQL Servidor Flexible, puede configurar alta disponibilidad con conmutación automática por error. Esta solución garantiza que los errores nunca provocan la pérdida de datos confirmados y que la base de datos no es un único punto de error en la arquitectura de software. Al configurar la alta disponibilidad, el servidor flexible aprovisiona y administra automáticamente una réplica en espera. Paga por el cómputo aprovisionado y almacenamiento para las réplicas principales y secundarias. Hay dos modelos de arquitectura de alta disponibilidad disponibles:

  • Alta disponibilidad con redundancia de zona. Esta opción proporciona aislamiento completo y redundancia de la infraestructura en varias zonas de disponibilidad. Ofrece el mayor nivel de disponibilidad, pero requiere configurar la redundancia de aplicaciones entre zonas. Elija alta disponibilidad con redundancia de zona cuando desee protegerse frente a cualquier error de infraestructura en la zona de disponibilidad y cuando la latencia en toda la zona de disponibilidad sea aceptable. Solo puede habilitar la alta disponibilidad con redundancia de zona al crear el servidor. La alta disponibilidad con redundancia de zona está disponible en un subconjunto de regiones de Azure donde la región admite varias zonas de disponibilidad y los recursos compartidos de archivos Premium con redundancia de zona.

  • Alta disponibilidad con redundancia local. Esta opción proporciona redundancia de infraestructura con menor latencia de red porque los servidores principal y en espera están en la misma zona de disponibilidad. Ofrece alta disponibilidad sin necesidad de configurar la redundancia de aplicaciones entre zonas. Elija alta disponibilidad con redundancia local cuando quiera lograr el mayor nivel de disponibilidad dentro de una sola zona de disponibilidad con la latencia de red más baja. La alta disponibilidad localmente redundante está disponible en todas las regiones de Azure donde puede usar Azure Database for MySQL Flexible Server.

Arquitectura de alta disponibilidad (HA) con redundancia de zona

Al implementar un servidor con alta disponibilidad con redundancia de zona, Azure crea dos servidores:

  • Un servidor principal en una zona de disponibilidad.
  • Un servidor de réplicas en espera en otra zona de disponibilidad de la misma región Azure. El servidor de réplicas en espera tiene la misma configuración que el servidor principal, incluido el nivel de proceso, el tamaño de proceso, el tamaño de storage y la configuración de red.

Puede elegir la zona de disponibilidad para el servidor principal y la réplica en espera. La colocación de los servidores de bases de datos en espera y las aplicaciones en espera en la misma zona reduce la latencia. También le ayuda a prepararse para situaciones de recuperación ante desastres y escenarios de zona inactiva.

Diagrama que muestra la arquitectura de alta disponibilidad con redundancia local.

Los archivos de datos y de registro se almacenan en almacenamiento redundante de zona (ZRS). El servidor en espera lee y reproduce continuamente los archivos de registro de la cuenta de almacenamiento del servidor principal, que protege la replicación a nivel de almacenamiento.

Si se produce una conmutación por error:

  • La réplica en espera se activa.
  • Los archivos de registro binarios del servidor principal se siguen aplicando al servidor en espera para conectarlo a la última transacción confirmada en el servidor principal.

En ZRS, los registros son accesibles incluso cuando el servidor principal no está disponible. Esta disponibilidad ayuda a garantizar que no se pierdan datos. Una vez que la réplica en espera se activa y se aplican los registros binarios, el servidor actual de réplica en espera toma el rol del servidor principal. Dns se actualiza para que las conexiones de cliente dirijan al nuevo servidor principal cuando el cliente se vuelva a conectar. La conmutación por error es totalmente transparente desde la aplicación cliente y no requiere ninguna acción por su parte. A continuación, en cuanto es posible, la solución de alta disponibilidad reactiva el servidor principal antiguo y lo coloca como servidor en espera.

Use el nombre del servidor de base de datos para conectar aplicaciones al servidor principal. La solución no expone información de réplica de espera para el acceso directo. Las confirmaciones y escrituras se confirman una vez que los archivos de registro se vacíen en el almacenamiento ZRS del servidor principal. Debido a la tecnología de replicación de sincronización que se usa en el almacenamiento ZRS, puede anticipar un aumento de latencia entre un 5 % y un 10 % para las escrituras y confirmaciones de la aplicación.

El servidor de bases de datos principal realiza automáticamente copias de seguridad tanto de las instantáneas como de los registros en almacenamiento con redundancia de zona.

Arquitectura de alta disponibilidad con redundancia local (HA)

Al implementar un servidor con alta disponibilidad con redundancia local, se crean dos servidores en la misma zona:

  • Un servidor principal
  • Un servidor de réplicas en espera que tenga la misma configuración que el servidor principal (nivel de cómputo, tamaño de cómputo, tamaño de almacenamiento y configuración de red).

El servidor en espera proporciona redundancia de infraestructura mediante una máquina virtual independiente (proceso). Esta redundancia reduce el tiempo de conmutación por error y la latencia de red entre la aplicación y el servidor de bases de datos debido a la coubicación.

Diagrama que muestra la arquitectura de alta disponibilidad con redundancia local.

Los archivos de datos y de registro se hospedan en locally redundante storage (LRS). El servidor en espera lee y reproduce continuamente los archivos de registro de la cuenta de almacenamiento del servidor principal, que está protegida por la replicación a nivel de almacenamiento.

Si se produce una conmutación por error:

  • La réplica en espera se activa.
  • Los archivos de registro binarios del servidor principal se siguen aplicando al servidor en espera para conectarlo a la última transacción confirmada en el servidor principal.

En LRS, los registros son accesibles incluso cuando el servidor principal no está disponible. Esta disponibilidad ayuda a garantizar que no se pierdan datos. Una vez que la réplica en espera se activa y se aplican los registros binarios, la réplica en espera actual asume el rol del servidor principal. Se actualiza el DNS para redirigir las conexiones a la nueva réplica principal cuando el cliente se vuelve a conectar. La conmutación por error es totalmente transparente desde la aplicación cliente y no requiere ninguna acción por su parte. A continuación, en cuanto es posible, la solución de alta disponibilidad reactiva el servidor principal antiguo y lo coloca como servidor en espera.

El nombre del servidor de base de datos conecta las aplicaciones al servidor principal. La información de réplica en espera no se expone para el acceso directo. Las confirmaciones y escrituras se confirman una vez que los archivos de registro se vacíen en el almacenamiento LRS del servidor principal. Dado que la réplica principal y la réplica en espera están en la misma zona, hay menos retraso de replicación y menor latencia entre el servidor de aplicaciones y el servidor de bases de datos. La configuración con redundancia local no proporciona alta disponibilidad cuando las infraestructuras dependientes están inactivas para la zona de disponibilidad específica. Hay tiempo de inactividad hasta que todos los servicios dependientes vuelvan a estar en línea en esa zona de disponibilidad.

El servidor de base de datos principal realiza automáticamente copias de seguridad de instantáneas y registros en almacenamiento con redundancia local.

Nota

Para alta disponibilidad con redundancia de zona y con redundancia local:

  • Si se produce un error, el tiempo necesario para que la réplica de espera asuma el rol de principal depende del tiempo necesario para reaplicar el registro binario desde la cuenta de almacenamiento principal hasta la réplica de espera. Para reducir el tiempo de conmutación por error, use claves principales en todas las tablas. Los tiempos de conmutación por error suelen oscilar entre 60 y 120 segundos.
  • El servidor en espera no está disponible para operaciones de lectura o escritura. Es un modo de espera pasivo para permitir una conmutación por error rápida.
  • Use siempre un nombre de dominio completo (FQDN) para conectarse al servidor principal. Evite usar una dirección IP para conectarse. Si se produce una conmutación por error, después de intercambiar los roles del servidor principal y en espera, podría cambiar el registro de dirección de DNS. Ese cambio impide que la aplicación se conecte al nuevo servidor principal si se usa una dirección IP en el cadena de conexión.

Proceso de conmutación por error

Durante el proceso de conmutación por error en Azure Database for MySQL, el sistema cambia automáticamente del servidor principal a la réplica en espera. Este modificador garantiza la continuidad y minimiza el tiempo de inactividad. Cuando el sistema detecta un error, promueve la réplica en espera para convertirse en el nuevo servidor principal. El sistema aplica los archivos de registro binarios del servidor principal original a la réplica en espera. Este proceso sincroniza la réplica en espera con la última transacción confirmada y garantiza que no se pierdan datos. Esta transición sin problemas ayuda a mantener la alta disponibilidad y confiabilidad del servicio de base de datos.

Nota

Para reducir la dependencia del tiempo de conmutación por error en el almacenamiento en caché de DNS, a partir de octubre de 2025, todos los nuevos servidores de alta disponibilidad creados con acceso público o conexión privada adoptarán la nueva arquitectura con un SLB dedicado para cada servidor de alta disponibilidad. Al gestionar la ruta de tráfico de datos de MySQL, SLB elimina la necesidad de cambiar el DNS durante la conmutación por error y mejora significativamente el rendimiento en estos eventos. Redirige el tráfico a la instancia principal actual durante la conmutación por error mediante reglas de equilibrio de carga. Los servidores existentes con acceso público o enlace privado se están migrando gradualmente para minimizar el impacto. Los clientes que prefieren la migración temprana pueden deshabilitar y volver a habilitar la alta disponibilidad. Esta característica no se admite para los servidores que usan acceso privado con integración de VNet.

Planeado: conmutación por error forzada

Azure Database for MySQL conmutación por error forzada del servidor flexible le permite forzar manualmente una conmutación por error. Esta funcionalidad le permite probar la funcionalidad con los escenarios de la aplicación y le ayuda a prepararse para interrupciones.

La conmutación por error forzada desencadena una conmutación por error que activa la réplica en espera para convertirse en el servidor principal mediante el mismo nombre de servidor de base de datos y la actualización del registro DNS. El servidor principal original se reinicia y cambia a la réplica en espera. Las conexiones de cliente se desconectan y necesitan volver a conectarse para reanudar sus operaciones.

El tiempo total de la conmutación por error depende de la carga de trabajo actual y del último punto de control. En general, tarda entre 60 y 120 segundos.

Nota

Durante una conmutación por error planificada, se genera un evento de Azure Resource Health. El evento representa el tiempo de conmutación por error durante el que el servidor no está disponible. Puede ver los eventos desencadenados cuando se selecciona en Resource Health en el panel izquierdo. El estado indica que la conmutación por error manual o iniciada por el usuario es No disponible y está etiquetada como Planeada. Por ejemplo, se activó una operación de conmutación por error planificada por un usuario autorizado. Si el recurso permanece en este estado durante un período prolongado, abra un ticket de soporte y nosotros le asistiremos.

No planeado: conmutación automática por error

El tiempo de inactividad del servicio no planeado puede producirse debido a fallos de software o de infraestructura, como fallos de computación, red o almacenamiento. Las interrupciones de energía también pueden afectar a la disponibilidad de la base de datos. Si la base de datos deja de estar disponible, la replicación en la réplica en espera se detiene y la réplica en espera se convierte en la base de datos principal. Se producen actualizaciones de DNS y los clientes se vuelven a conectar al servidor de bases de datos y reanudan sus operaciones.

El tiempo de conmutación por error general suele oscilar entre 60 y 120 segundos. Sin embargo, en función de la actividad del servidor de base de datos principal en el momento de la conmutación por error (como transacciones grandes y tiempo de recuperación), la conmutación por error puede tardar más tiempo.

Nota

Se genera un evento de Azure Resource Health durante una conmutación por error no planeada. El evento representa el tiempo de conmutación por error cuando el servidor no está disponible. Puede ver los eventos desencadenados al seleccionar Resource Health en el panel izquierdo. La conmutación automática por error muestra un estado no disponible y se etiqueta como No planeado.

Por ejemplo, No disponible: se desencadenó automáticamente una operación de conmutación por error (no planeada). Si el recurso permanece en este estado durante mucho tiempo, abra un ticket de soporte soporte y podremos ayudarle.

Funcionamiento de la detección automática de conmutación por error en servidores habilitados para alta disponibilidad

El servidor principal y el servidor secundario tienen cada uno dos puntos de conexión de red:

  • Punto de conexión de cliente: los clientes se conectan y ejecutan consultas en la instancia mediante este punto de conexión.
  • Punto de conexión de administración: se usa internamente para las comunicaciones de servicio a los componentes de administración y para conectarse al almacenamiento de back-end.

El componente del monitor de estado realiza continuamente las siguientes comprobaciones:

  • El monitor envía una señal de ping al terminal de la red de gestión del nodo. Si se produjese un error en esta comprobación dos veces seguidas, se desencadenará una operación de conmutación automática por error. Esta comprobación de estado aborda escenarios como la falta de disponibilidad del nodo o la falta de respuesta debido a problemas del sistema operativo, problemas de red entre los componentes de administración y los nodos y problemas similares.
  • El monitor ejecuta una consulta sencilla en la instancia. Si las consultas no se ejecutasen, se desencadenará la conmutación automática por error. Esta comprobación de estado aborda escenarios como fallos, paradas o bloqueos del demonio de MySQL, así como problemas de almacenamiento de back-end y otros problemas similares.

Nota

La comprobación de estado no supervisa los problemas de conectividad entre la aplicación y el punto de conexión de red del cliente (acceso privado/público). Estos problemas pueden producirse en la ruta de acceso de red, en el punto de conexión o en problemas de DNS en el lado cliente. Si usa acceso privado, asegúrese de que las reglas del grupo de seguridad de red de la red virtual no bloqueen la comunicación con el punto de conexión de red del cliente en la instancia en el puerto 3306. En el caso de los accesos públicos, asegúrese de que se establezcan las reglas de cortafuegos y se permita el tráfico de red en el puerto 3306 (si la ruta de acceso de red tiene otros cortafuegos). También debe ocuparse de la resolución DNS desde el lado de la aplicación cliente.

Supervisión de alta disponibilidad

Para comprobar el estado de configuración de alta disponibilidad del servidor, use el estado de alta disponibilidad en el panel de alta disponibilidad del servidor en el portal.

Estado Descripción
NotEnabled La alta disponibilidad no está habilitada.
ReplicatingData El servidor en espera se sincroniza con el servidor principal durante el aprovisionamiento del servidor de alta disponibilidad o cuando se habilita la opción de alta disponibilidad.
FailingOver El servidor de bases de datos está en proceso de conmutar por error desde el principal al de en modo de espera.
Healthy La opción de alta disponibilidad está habilitada.
RemovingStandby El proceso de eliminación está en curso cuando se deshabilita la opción de alta disponibilidad.

Para supervisar el estado del servidor de alta disponibilidad, use las métricas siguientes.

Nombre para mostrar de la métrica Métrica Unidad Descripción
Estado de HA ha_io_running Estado Estado de HA muestra el estado de la replicación de HA. El valor de la métrica es 1 si el subproceso de E/S se está ejecutando y 0 si no.
Estado de SQL de alta disponibilidad ha_sql_running Estado El estado de SQL de alta disponibilidad muestra el estado de la replicación de alta disponibilidad. El valor de la métrica es 1 si el subproceso de SQL se está ejecutando y 0 si no.
Intervalo de replicación de alta disponibilidad retardo de replicación Segundos El retraso de replicación es el número de segundos en que el modo de espera está detrás de la reproducción de las transacciones recibidas en el servidor principal.

Limitaciones

Tenga en cuenta las siguientes consideraciones al usar alta disponibilidad:

  • Puede configurar la alta disponibilidad redundante por zona solo durante la creación del servidor.

  • El nivel de cómputo de ráfagas no admite alta disponibilidad.

  • Al reiniciar el servidor de base de datos principal para aplicar cambios de parámetro estáticos, también se reinicia la réplica en espera.

  • La solución activa el modo GTID porque usa GTID. Compruebe si la carga de trabajo tiene restricciones o limitaciones en la replicación con GTID.

Nota

El crecimiento automático del almacenamiento está habilitado de forma predeterminada para un servidor configurado de alta disponibilidad y no se puede deshabilitar.

Problemas conocidos

Azure Database for MySQL Flexible Server utiliza la replicación nativa de MySQL en el sistema backend. Existe un problema conocido en MySQL Community Edition 8.0 y versiones posteriores que pueden interrumpir la replicación al realizar una operación DELETE multitable que se basa en restricciones de clave externa con ON DELETE CASCADE. Este problema se registra como el bug 102586 de MySQL. Como resultado, al habilitar la alta disponibilidad en Azure Database for MySQL servidor flexible, evite usar eliminaciones en cascada con claves externas, ya que este patrón puede provocar errores de replicación y podría afectar a la disponibilidad del servidor.

Comprobaciones de mantenimiento

Al configurar la alta disponibilidad (HA) para Azure Database for MySQL, las comprobaciones de estado desempeñan un papel fundamental en el mantenimiento de la confiabilidad y el rendimiento de la base de datos. Estas comprobaciones monitorean continuamente el estado y la salud de las réplicas principales y en espera, lo que garantiza que detectan cualquier problema rápidamente. Mediante el seguimiento de varias métricas, como la capacidad de respuesta del servidor, el retraso de replicación y el uso de recursos, las comprobaciones de estado ayudan a garantizar que los procesos de conmutación por error se puedan ejecutar sin problemas, lo que minimiza el tiempo de inactividad y evita la pérdida de datos. Las comprobaciones de estado configuradas correctamente son esenciales para lograr el nivel deseado de disponibilidad y resistencia en la configuración de la base de datos.

Supervisión del estado

Puede supervisar el estado de la configuración de alta disponibilidad a través del Azure Portal. Entre las métricas que se deben observar se encuentran:

  • La capacidad de respuesta del servidor: indica si se puede acceder al servidor principal.
  • El retraso de replicación: mide el retraso entre la réplica principal y la réplica en espera, lo que garantiza la coherencia de los datos.
  • Uso de recursos: Supervisa el uso de CPU, memoria y almacenamiento para evitar cuellos de botella.

Contenido relacionado

  • Alta disponibilidad
  • Continuidad empresarial
  • ** Alta disponibilidad redundante por zona
  • copia de seguridad y recuperación
  • Last updated on