Compartir a través de

Confiabilidad en Azure Database for MySQL

Azure Database for MySQL es un servicio de base de datos totalmente administrado diseñado para ofrecer un control y flexibilidad pormenorizados sobre las funciones de administración de bases de datos y las opciones de configuración. El servicio proporciona funcionalidades de alta disponibilidad y recuperación ante desastres en función de sus requisitos.

Al usar Azure, relibilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para admitir resiliencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que la Azure Database for MySQL sea resistente a una variedad de interrupciones y problemas potenciales, incluidos fallos transitorios, interrupciones de la zona de disponibilidad, interrupciones de la región y el mantenimiento del servicio. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Database for MySQL.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Azure Database for MySQL para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Architecture best practices for Azure Database for MySQL in the Azure Well-Architected Framework.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

Al trabajar con Azure Database for MySQL, se implementa un server, que representa los recursos de proceso y almacenamiento necesarios para admitir el servidor de bases de datos. Puede implementar una o varias bases de datos en el servidor.

Puede implementar servidores en varios niveles de proceso: ampliable, de uso general y optimizado para memoria, cada uno de los cuales está optimizado para diferentes tipos de cargas de trabajo.

Para obtener más información sobre la arquitectura de servicio general y los modelos de implementación, consulte ¿Qué es Azure Database for MySQL?.

Arquitectura física

  • Cómputo y separación de almacenamiento: Azure Database for MySQL usa una arquitectura de separación de cómputo y almacenamiento para soportar alta disponibilidad. El motor de base de datos se ejecuta en una máquina virtual. Los archivos de datos se almacenan en Azure Storage, que mantiene sincrónicamente tres copias de los datos para protegerse frente a errores de hardware de almacenamiento. En función de la configuración de alta disponibilidad del servidor, los archivos de datos se pueden almacenar en el almacenamiento con redundancia de zona (ZRS) o en el almacenamiento con redundancia local (LRS).

  • Alta disponibilidad: Opcionalmente, puede habilitar una configuración de alta disponibilidad en el servidor. Al habilitar la configuración de alta disponibilidad, el servicio aprovisiona y mantiene un servidor de réplica en espera activa. Los cambios de datos en el servidor principal se replican sincrónicamente en el servidor de réplica en espera para garantizar una pérdida de datos cero durante un error del servidor principal.

    La arquitectura separa la capa de proceso de la capa de almacenamiento, lo que permite al servicio controlar los distintos tipos de errores de forma adecuada. Para lograr una mayor resistencia, puede distribuir los servidores entre zonas de disponibilidad.

    Un servidor de réplica en espera se implementa en la misma configuración de máquina virtual que el servidor principal, incluidos los núcleos virtuales, el almacenamiento y la configuración de red.

    Puede cambiar entre servidores mediante la realización de una conmutación por error. Hay dos tipos de conmutación por error: conmutaciones por error no planeadas, que se usan cuando se produce un error en el servidor principal y las conmutaciones por error planeadas, que se usan en otros escenarios en los que es necesario minimizar el tiempo de inactividad de la aplicación durante una conmutación por error.

    Para obtener más información, consulte Alta disponibilidad en Azure Database for MySQL.

  • Backups: Azure Database for MySQL crea automáticamente copias de seguridad del servidor. Para obtener más información, consulte Copia de seguridad y restauración.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Las aplicaciones deben controlar los errores de conectividad transitorios que pueden producirse durante el mantenimiento, las operaciones de escalado o las interrupciones de red. Siga estas recomendaciones:

  • Cuando la aplicación encuentre errores transitorios, vuelva a intentar la operación mediante retroceso exponencial. Aumente el retraso entre reintentos y limite el número de intentos. Si la operación sigue produciendo un error después de los reintentos máximos, considérela un fracaso.
  • Siempre que sea posible, use bibliotecas cliente que controlen automáticamente los reintentos.
  • Los errores transitorios que se producen durante las operaciones de escritura requieren una consideración más cuidadosa. Considere la posibilidad de hacer que las operaciones de escritura sean idempotentes, por lo que se pueden ejecutar de forma segura varias veces.

Resistencia a errores de zona de disponibilidad

Availability zones son grupos de centros de datos físicamente independientes dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Puede seleccionar su tipo de soporte de zona de disponibilidad a través de la configuración de alta disponibilidad. Al habilitar la alta disponibilidad, se implementa un servidor de réplica en espera junto con el servidor principal. Este modelo de alta disponibilidad ayuda a garantizar que los datos confirmados nunca se pierdan durante los errores. Cualquiera que sea el modelo de implementación de alta disponibilidad que elija, los datos se confirman sincrónicamente en ambos servidores de réplica, principal y en espera. Si se produce una interrupción en el servidor principal, el servidor cambia automáticamente al modo de espera del servidor réplica.

Los datos se almacenan en Azure Files premium Storage. En función de la configuración de alta disponibilidad del servidor, usa almacenamiento con redundancia de zona o almacenamiento con redundancia local (LRS), que almacena tres copias de datos dentro o entre zonas de disponibilidad.

Azure Database for MySQL admite dos tipos de configuración de zona de disponibilidad cuando se usa alta disponibilidad:

  • Alta disponibilidad con redundancia de zona: La redundancia de zona proporciona el nivel más alto de resistencia de zona mediante la implementación de un servidor principal en una zona de disponibilidad y un servidor de réplica en espera en una zona de disponibilidad diferente. El servidor de réplicas en espera usa una configuración de red, almacenamiento y proceso similar al principal. Una configuración con redundancia de zona proporciona aislamiento físico de toda la pila entre los servidores principal y en espera.

    Seleccione las zonas de disponibilidad para los servidores principales y en espera.

    Se recomiendan implementaciones con redundancia de zona para servidores de producción.

    Las operaciones de escritura pueden experimentar un pequeño aumento de la latencia de confirmación porque el servicio replica de forma sincrónica los datos en el servidor en espera. En promedio, puede esperar una mayor latencia del 5 al 10 % para las escrituras y confirmaciones de la aplicación, pero el impacto varía según la carga de trabajo, la SKU seleccionada y la región.

  • Alta disponibilidad con redundancia local: Los servidores principales y en espera usan la misma zona de disponibilidad. Si se produce una interrupción en el servidor principal, pero la zona sigue operativa, el servidor conmuta automáticamente al servidor en espera.

    Una implementación con redundancia local proporciona alta disponibilidad dentro de una sola zona de disponibilidad. Protege contra errores de nivel de nodo y también ayuda a reducir el tiempo de inactividad de la aplicación durante los eventos de tiempo de inactividad planeados y no planeados. Sin embargo, no protege contra una interrupción en esa zona. En las regiones con zonas de disponibilidad, este tipo de configuración también se denomina a veces zonal o de una sola zona.

    Se recomienda una alta disponibilidad con redundancia local solo en escenarios específicos:

    • Cuando tiene aplicaciones inusualmente sensibles a la latencia, ha validado la necesidad de minimizar la latencia entre la réplica principal y la secundaria, y usted mismo ha planificado la resiliencia de zona utilizando otros enfoques arquitectónicos.
    • Cuando se implementa en una región que no admite zonas de disponibilidad, la región funciona eficazmente como una sola zona, lo que hace que la alta disponibilidad con redundancia local sea la única opción de alta disponibilidad.

    Dado que los servidores están en la misma zona, puede reducir la latencia de escritura a las aplicaciones que implemente dentro de esa zona.

Si configura el servidor sin alta disponibilidad, se ejecuta en un solo servidor. Si ese servidor o su zona deja de funcionar, el servidor no está disponible.

Requisitos

  • Compatibilidad regional: El soporte de Azure Database for MySQL para las configuraciones de zona de disponibilidad varía entre las regiones de Azure. Para obtener una lista completa de las regiones, los tipos de compatibilidad de las zonas de disponibilidad y las consideraciones específicas para esa región, consulte regiones de Azure.

  • Nivel de servicio: La alta disponibilidad requiere niveles de uso general o optimizados para memoria. El nivel Burstable no admite alta disponibilidad (con redundancia de zona o con redundancia local).

Costo

Al habilitar la alta disponibilidad, se crea el servidor en espera y se factura a la misma velocidad que la principal. La configuración de la zona de disponibilidad no afecta al costo. No hay cargos por la replicación de datos dentro o entre zonas de disponibilidad. Dependiendo del volumen de almacenamiento de copia de seguridad, también se le puede facturar por el almacenamiento de copia de seguridad. Para obtener información detallada sobre los precios, consulte Azure Database for MySQL precios.

Consideraciones

  • Claves principales: Se recomienda usar claves principales en todas las tablas, ya que este enfoque reduce el tiempo de replicación y conmutación por error.
  • Limitaciones y problemas conocidos: Revise la lista de limitaciones y problemas conocidos.

Configurar soporte de zonas de disponibilidad

Para configurar la compatibilidad con zonas de disponibilidad para un servidor, configure las opciones de alta disponibilidad.

Nota:

Cuando selecciona qué zonas de disponibilidad usar, en realidad está seleccionando la zona de disponibilidad lógica. Si implementa otros componentes de carga de trabajo en una suscripción de Azure diferente, pueden usar un número de zona de disponibilidad lógica diferente para acceder a la misma zona de disponibilidad física. Para obtener más información, consulte zonas de disponibilidad física y lógica.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los servidores están configurados con compatibilidad con zonas de alta disponibilidad y disponibilidad y todas las zonas de disponibilidad están operativas.

  • Operación entre zonas: Las aplicaciones cliente mySQL se conectan al servidor principal mediante el nombre de dominio completo (FQDN) del servidor de bases de datos. Evite usar la dirección IP del servidor principal porque la dirección IP puede cambiar, incluso durante las conmutaciones por error.

    Azure Database for MySQL usa una configuración activa/pasiva en la que el servidor principal controla todas las conexiones y consultas de base de datos en la zona de disponibilidad principal. El servidor de réplicas en espera no atiende el tráfico de cliente durante las operaciones normales.

  • Replicación de datos entre zonas: Las escrituras se confirman en el servidor principal y se escriben sincrónicamente en los registros del servidor en espera mediante ZRS. El servidor principal no espera a que el servidor en espera aplique los registros, pero dado que los registros están en ZRS, están disponibles incluso si se produce un error de réplica o zona.

    Los efectos de la replicación son diferentes en función de la configuración de zona de disponibilidad que use el servidor:

    • Con redundancia de zona: Dado que los servidores están en zonas independientes, este enfoque garantiza una pérdida de datos cero durante un error de zona. Esta situación también se conoce como lograr un objetivo de punto de recuperación (RPO) de cero en caso de fallos de zona.

      Sin embargo, la replicación entre zonas podría introducir una pequeña cantidad de latencia adicional. En promedio, puede esperar una mayor latencia del 5 al 10 % para las escrituras y confirmaciones de la aplicación, pero el impacto varía según la carga de trabajo, la SKU seleccionada y la región.

    • Localmente redundante: no se replica ningún tráfico entre zonas.

    Nota:

    El sistema replica todos los cambios en tiempo real en el servidor de réplicas en espera, incluidos los errores de usuario no deseados, como una eliminación accidental de una tabla o actualizaciones de datos incorrectas. Debido a la replicación inmediata, no puede usar la réplica en espera para la recuperación. Para recuperarse de errores de usuario, debe realizar una restauración en un punto específico en el tiempo desde un respaldo. Para obtener más información, consulte Copia de seguridad y restauración.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando los servidores están configurados para alta disponibilidad y compatibilidad con zonas de disponibilidad y hay una interrupción en una zona de disponibilidad.

  • Detección y respuesta: Azure comprueba periódicamente el estado de los servidores principal y en espera. Después de varios pings, si la supervisión de estado detecta que no se puede acceder a un servidor principal, el servicio inicia una conmutación automática al servidor en espera. El algoritmo de supervisión de estado usa varios puntos de datos para evitar situaciones de falsos positivos.

    En caso de error de zona, el comportamiento es diferente en función de la configuración de zona de disponibilidad que use el servidor:

    • Zone-redundant: Azure Database for MySQL detecta automáticamente errores de zona de disponibilidad supervisando continuamente varios puntos de conexión de servidor. Para obtener más información, consulte cómo funciona la detección automática de conmutación por error en servidores habilitados para alta disponibilidad.

      Para ver los posibles tipos de estado de alta disponibilidad, consulte Supervisión de la alta disponibilidad. Cuando se produce un error en una zona, Azure inicia una conmutación por error no planificada al servidor en espera sin necesidad de tomar medidas.

    • Con redundancia local: Los servidores principales y en espera no están disponibles si la zona de disponibilidad que hospeda un servidor con redundancia local deja de estar disponible. En este escenario, el servicio no proporciona conmutación automática por error. Es responsable de detectar la interrupción de zona y realizar acciones de recuperación, como restaurar copias de seguridad con redundancia de zona en un servidor independiente en otra zona de disponibilidad o región.

  • Notification: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar Resource Health alertas para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

    Azure Database for MySQL genera un evento de Azure Resource Health cuando se produce una conmutación por error imprevista.

  • Solicitudes activas: Cuando una zona de disponibilidad deja de estar disponible, es posible que se finalicen las solicitudes en curso a los servidores de la zona afectada. Las aplicaciones deben reintentar estas solicitudes. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

  • Pérdida de datos esperada: La cantidad de pérdida de datos depende de la configuración de la zona de disponibilidad del servidor.

    • Redundante por zona: Se anticipa una pérdida de datos cero durante el fallo de zona debido a la replicación sincrónica entre los servidores principal y en espera en distintas zonas.

    • Con redundancia local: Los datos de los servidores de la zona afectada no están disponibles hasta que se recupere la zona.

  • Tiempo de inactividad esperado: La cantidad de tiempo de inactividad depende de la configuración de zona de disponibilidad que usa el servidor.

    • Con redundancia de zona: La conmutación por error se completa normalmente en un plazo de 60 a 120 segundos. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

    • Con redundancia local: Los servidores de una zona afectada no están disponibles hasta que se recupere la zona de disponibilidad.

  • Redistribución: El comportamiento de reenrutamiento del tráfico depende de la configuración de zona de disponibilidad que usa el servidor.

    • Con redundancia de zona: Después de la conmutación por error, el servidor en espera anterior se convierte en el nuevo servidor principal y comienza a aceptar nuevas conexiones. Azure establece automáticamente un servidor en espera en la zona principal original después de recuperarse. Para más información, consulte Conmutación por error no planeada.

    • Con redundancia local: Cuando una zona no está disponible, el servidor no está disponible. Si tiene un servidor independiente que ha creado previamente en otra zona de disponibilidad o región, es responsable de redirigir el tráfico a ese servidor.

Recuperación de zona

El comportamiento de recuperación de zona depende de la configuración de zona de disponibilidad que usa el servidor.

  • Zone-redundant: Cuando se recupera la zona de disponibilidad, Azure Database for MySQL vuelve a generar automáticamente el servidor en espera en la zona recuperada y lo sincroniza con la principal actual. A continuación, la zona recuperada actúa como ubicación en espera. El servicio no mueve automáticamente el rol principal a la zona original para evitar interrupciones innecesarias. Puede iniciar manualmente una conmutación por error planeada si desea devolver la principal a la zona original.

  • Con redundancia local: Una vez que la zona está en buen estado, los servidores de la zona están disponibles de nuevo. Es responsable de cualquier procedimiento de recuperación de zona y sincronización de datos que requieran las cargas de trabajo.

Prueba de fallos de zona

Las opciones para probar errores de zona dependen de la configuración de zona de disponibilidad que usa la instancia.

Resistencia a errores en toda la región

Azure Database for MySQL admite réplicas de lectura entre regiones, que puede usar para mantener copia sincronizada de la base de datos en una región diferente para una recuperación más rápida.

También puede usar copias de seguridad con redundancia geográfica, en regiones admitidas, para proporcionar recuperación entre regiones. Sin embargo, las copias de seguridad suelen implicar más tiempo de inactividad y pérdida de datos que la replicación. Para obtener más información, consulte Copia de seguridad y restauración.

Réplicas de lectura entre regiones

Puede implementar réplicas de lectura para proteger las bases de datos frente a errores de nivel de región. Cada réplica de lectura es un servidor Azure Database for MySQL independiente. Cuando colocas una réplica de lectura en una segunda región de Azure, el servidor de bases de datos puede proporcionar resiliencia ante un problema que afecte a toda la región. Puede implementar hasta diez réplicas de lectura, que opcionalmente pueden estar en diferentes regiones de Azure. La tecnología de replicación física de MySQL actualiza las réplicas de lectura de forma asincrónica desde el servidor de origen en la región primaria y pueden quedar desfasadas con respecto al origen. Las réplicas de lectura entre regiones pueden servir opcionalmente cargas de trabajo de solo lectura para reducir la latencia de las aplicaciones distribuidas globalmente o descargar el tráfico de lectura desde el servidor de origen. Para obtener más información sobre las características y consideraciones de réplica de lectura, consulte Réplicas de lectura.

Si se produce un error en la región primaria, puede conmutar manualmente para que la réplica secundaria se convierta en el servidor principal. Para ello, detenga el proceso de replicación, que promueve la réplica de lectura para que sea un servidor de lectura y escritura. Debido a la replicación asincrónica, la conmutación por error puede provocar la pérdida de datos. A continuación, la aplicación debe conectarse al nuevo servidor principal y es responsable de esta reconfiguración de la aplicación.

Nota:

En esta sección se resume alguna de la información importante sobre cómo las réplicas de lectura pueden admitir resiliencia ante fallos a nivel regional. También puede usar réplicas de lectura para mejorar el rendimiento y admitir bases de usuarios distribuidas geográficamente a gran escala. Para obtener más información, consulte Réplicas de lectura.

Requisitos

  • Region support: Puede crear réplicas de lectura entre regiones en cualquier región que admita Azure Database for MySQL. No está limitado a las regiones emparejadas de Azure.

  • Niveles de cómputo: Los niveles de cómputo de uso general y optimizados para memoria admiten réplicas de lectura. El nivel Ampliable no admite réplicas de lectura.

Consideraciones

  • Diferencias de configuración: Al crear una réplica, hereda varias opciones de configuración del servidor de origen, incluida la generación de procesos, los núcleos virtuales y el almacenamiento. Puede personalizar estos valores en la réplica de lectura una vez que ésta sea creada. Sin embargo, es mejor usar valores iguales o mayores para asegurarse de que la réplica puede mantenerse al día con los cambios en el origen.

  • Supervisión del retraso de replicación: El proceso de replicación asincrónica requiere un retraso de replicación, que puede variar dependiendo de varios factores. Cuando el retraso de replicación es muy alto, es posible que el servidor experimente problemas. Es importante supervisar el retraso de replicación para que pueda mitigar los problemas antes de que se escalen. Para más información, consulte Supervisión de la replicación.

  • Alta disponibilidad: Las réplicas de lectura no pueden tener alta disponibilidad habilitada y, cuando se conmutan por error para convertirse en el servidor principal, tampoco tienen alta disponibilidad. Usted es responsable de realizar la configuración de alta disponibilidad después de conmutar por error a una réplica.

Costo

Las réplicas de lectura incurren en costos de proceso y almacenamiento, así como cargos por transferencia de datos entre regiones para la replicación. Para obtener información detallada sobre los precios, consulte los precios de Azure Database for MySQL y del ancho de banda.

Configuración de la compatibilidad con varias regiones

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando el servidor está configurado con una réplica de lectura en otra región y todas las regiones están operativas:

  • Enrutamiento del tráfico entre regiones: En las operaciones normales, la aplicación debe dirigir el tráfico de lectura y escritura al servidor de origen en la región primaria. Opcionalmente, puede dirigir las solicitudes de lectura a la réplica de lectura.

  • Replicación de datos entre regiones: Las réplicas de lectura entre regiones usan la replicación asincrónica para minimizar el impacto en el rendimiento del servidor de origen. La cantidad de retraso de replicación depende de varios factores, incluida la carga de escritura y la latencia entre el servidor de origen y las réplicas. El retraso de replicación suele ser al menos varios minutos, pero puede ser mucho más largo. Para obtener más información, consulte Monitor replication y para obtener instrucciones detalladas, consulte Monitor replication in the Azure portal.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando el servidor está configurado con una réplica de lectura en otra región y hay una interrupción en la región primaria:

  • Detección y respuesta: Usted es responsable de detectar una interrupción en la región principal y desencadenar manualmente una conmutación por error. Esta acción puede provocar la pérdida de cualquier dato no replicado.

    Importante

    Usted es responsable de desencadenar la conmutación por error. Azure no realiza la conmutación automática a las réplicas de lectura, incluso si ocurre una falla regional.

    La conmutación por error requiere que:

    1. Detenga la replicación. Se trata de un procedimiento irreversible y el servidor no se puede volver a convertir en una réplica. El proceso da como resultado la pérdida de datos. Para obtener más información sobre las implicaciones de esta acción, consulte Detener la replicación.
    2. Reconfigure su aplicación para que use el nuevo servidor primario.

    Para obtener más información, consulte Conmutación por error.

  • Notification: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: Todas las conexiones activas a la región de origen se quitan si el servidor de origen no está disponible. Las aplicaciones deben reintentar la realización de conexiones al nuevo servidor principal una vez completado el proceso de conmutación por error.

  • Pérdida de datos esperada: Durante una interrupción en la región, debe realizar una conmutación por error para detener la replicación. Este proceso da como resultado la pérdida permanente de cualquier dato no replicado.

    La cantidad de pérdida de datos depende del retraso de replicación en el momento de la interrupción. El retraso de replicación suele ser al menos varios minutos, pero puede ser mucho más largo. Para más información, consulte Supervisión de la replicación.

  • Tiempo de inactividad esperado: La detención de la replicación normalmente se completa en un plazo de 2 minutos después de que se desencadene. Es responsable de volver a configurar las aplicaciones para conectarse al nuevo servidor principal y el tiempo necesario para realizar la reconfiguración también contribuye al tiempo de inactividad general.

  • Reenrutamiento del tráfico: Es responsable de volver a configurar las aplicaciones para conectarse al nuevo servidor principal.

    Nota:

    Después de conmutar por error una réplica de lectura para convertirse en el servidor principal, el servidor no tiene habilitada la alta disponibilidad. Debe habilitar la alta disponibilidad manualmente o incluirla en la automatización.

Recuperación de regiones

Cuando se recupera la región, es responsable de las actividades de conmutación por recuperación para reanudar las operaciones en la región primaria. Microsoft no mueve automáticamente el servidor principal. Puede crear una nueva réplica de lectura en la región primaria y, a continuación, realizar otro proceso de conmutación por error para restaurar operaciones en la región primaria. Tenga en cuenta uno de los enfoques siguientes, en función de si la aplicación puede tolerar tiempo de inactividad o pérdida de datos:

  • Desconecte la aplicación y espere a que la replicación esté al tanto de todos los cambios. Este enfoque requiere tiempo de inactividad de la aplicación, aproximadamente igual al retraso de replicación.
  • Realice la conmutación por error y acepte la pérdida de los datos no replicados.

Recuerde que también es responsable de volver a configurar las aplicaciones para conectarse al nuevo servidor principal según sea necesario.

Prueba de fallos de región

Pruebe periódicamente los procedimientos de conmutación por error de réplica de lectura para asegurarse de que los procesos son válidos y que las funcionalidades cumplen los requisitos de RTO y RPO.

Puede realizar la conmutación de una réplica de lectura para que se convierta en el servidor principal en cualquier momento, incluso cuando todas las regiones están en buen estado. Se recomienda realizar estas pruebas en un entorno no productivo, ya que eso puede provocar pérdida de datos y requiere una recuperación manual.

Como parte de la estrategia de recuperación ante desastres, ejecute periódicamente los simulacros de recuperación completa. Estos simulacros deben incluir la validación de datos, las pruebas de funcionalidad de la aplicación y los procedimientos de reversión documentados.

Copias de seguridad y restauración

Azure Database for MySQL realiza automáticamente copias de seguridad que proporcionan funcionalidades de recuperación a un momento dado y le ayudan a protegerse frente a daños accidentales y la eliminación de datos. Microsoft administra completamente las copias de seguridad, no interrumpe la disponibilidad del servidor e incluye copias de seguridad completas y copias de seguridad del registro de transacciones.

  • Almacenamiento de copia de seguridad: Si el servidor está configurado con alta disponibilidad con redundancia de zona, las copias de seguridad se almacenan en el almacenamiento con redundancia de zona (ZRS). En el caso de los servidores configurados sin alta disponibilidad o con alta disponibilidad con redundancia local, las copias de seguridad se almacenan en almacenamiento con redundancia local (LRS).

    En las regiones emparejadas de Azure, puede configurar el almacenamiento de copia de seguridad con redundancia geográfica (GRS) en el momento de la creación del servidor para replicar copias de seguridad en la región emparejada de Azure, proporcionando una protección adicional frente a fallos de región. Las copias de seguridad se replican de forma asincrónica.

    El período de retención de copia de seguridad predeterminado es de 7 días, con la opción de ampliar la retención hasta 35 días. Todas las copias de seguridad están cifradas.

  • Restaurar: La recuperación a un momento dado le permite restaurar la base de datos a cualquier momento dentro del período de retención de copia de seguridad. El proceso de restauración crea un nuevo servidor de bases de datos con un nuevo nombre de servidor proporcionado por el usuario, desde el que puede usar as-is o copiar datos.

    Al restaurar una copia de seguridad con redundancia geográfica, se crea un nuevo servidor en la región emparejada. En algunas regiones, puede usar Universal Geo-Restore para restaurar una copia de seguridad con redundancia geográfica en una región que no sea la emparejada con la primaria.

    Esta funcionalidad es útil para recuperarse de modificaciones accidentales de datos, errores de aplicación o escenarios de prueba.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Para obtener más información, vea Backup and restore in Azure Database for MySQL.

Resistencia al mantenimiento del servicio

Azure Database for MySQL controla automáticamente las tareas de mantenimiento críticas, incluida la aplicación de revisiones del hardware subyacente, el sistema operativo y el motor de base de datos. El servicio incluye actualizaciones de seguridad, actualizaciones de software y actualizaciones de versiones secundarias como parte del mantenimiento planeado. Para obtener más información, consulte Scheduled maintenance in Azure Database for MySQL.

Para asegurarse de que el servidor permanece disponible durante las ventanas de mantenimiento, siga estas recomendaciones:

  • Evite las operaciones de administración durante los períodos de mantenimiento: No realice operaciones de administración del servidor mientras el mantenimiento está en curso, ya que estas operaciones pueden afectar a la confiabilidad del servidor.

  • Use el mantenimiento casi sin tiempo de inactividad: Si el servidor tiene alta disponibilidad habilitada y cumple otros criterios de idoneidad, las operaciones de mantenimiento suelen completarse en un plazo de 10 a 30 segundos. Si tiene alta disponibilidad habilitada, las operaciones de mantenimiento suelen usar actualizaciones graduales para minimizar el tiempo de inactividad. Las actividades de mantenimiento periódicas, como las actualizaciones de versiones secundarias, se producen primero en la réplica en espera. Para reducir el tiempo de inactividad, el modo de espera se promueve a principal para que las cargas de trabajo puedan mantenerse mientras se aplican las tareas de mantenimiento en el nodo restante. Esta secuenciación se aplica tanto si el servidor usa alta disponibilidad con redundancia zonal como con redundancia local. Para obtener más información, consulte Mantenimiento casi sin tiempo de inactividad.

  • Configurar ventanas de mantenimiento personalizadas: Puede configurar la programación de mantenimiento para que se administre por el sistema o definir una ventana de mantenimiento personalizada para minimizar el impacto en las operaciones empresariales. También puede reprogramar las operaciones de mantenimiento planeado. Programe el mantenimiento durante períodos de baja actividad para minimizar el impacto empresarial. Para obtener más información, consulte Administrar la configuración de mantenimiento programado para Azure Database for MySQL.

  • Implemente la lógica de reintento: Asegúrese de que las aplicaciones pueden controlar breves interrupciones de conectividad que pueden producirse durante los reinicios de mantenimiento. Para que las aplicaciones sean resistentes a estos tipos de problemas, consulte Guía sobre resistencia a errores transitorios .

  • Habilite el mantenimiento de Virtual Canary en servidores de desarrollo y pruebas: El mantenimiento de Virtual Canary ofrece acceso anticipado a las actualizaciones. Al habilitarlo en servidores de desarrollo y pruebas, puede comprobar que la carga de trabajo no se ve afectada por las próximas actualizaciones antes de que lleguen a los servidores de producción. Para obtener más información, consulte Mantenimiento de Canario virtual.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, vea SLAs for servicios en línea.

Azure Database for MySQL proporciona acuerdos de nivel de servicio de disponibilidad diferentes en función de la configuración del servidor:

  • Servidores configurados con redundancia de zona para alta disponibilidad.
  • Servidores configurados con alta disponibilidad redundante local.
  • Servidores configurados sin alta disponibilidad.

Contenido relacionado

  • Last updated on