Alta disponibilidad en Azure Database for MySQL

SE APLICA A: Azure Database for MySQL: Servidor único

Importante

El servidor único de Azure Database for MySQL está en la ruta de retirada. Se recomienda encarecidamente actualizar al servidor flexible de Azure Database for MySQL. Para más información sobre la migración al servidor flexible de Azure Database for MySQL, consulte ¿Qué ocurre con Azure Database for MySQL con servidor único?

El servicio Azure Database for MySQL proporciona un alto nivel de disponibilidad garantizada gracias al Acuerdo de Nivel de Servicio (SLA) respaldado económicamente con un tiempo de actividad del 99,99 %. Azure Database for MySQL proporciona alta disponibilidad durante los eventos planeados, como la operación de proceso de escalado iniciada por el usuario y también cuando se producen eventos no planeados, como los errores subyacentes de hardware, software o red. Azure Database for MySQL puede recuperarse rápidamente de las circunstancias más críticas, lo que garantiza que las aplicaciones prácticamente no tengan tiempo de inactividad al usar este servicio.

Azure Database for MySQL resulta adecuado para ejecutar bases de datos esenciales que requieren un tiempo de actividad elevado. Basado en la arquitectura de Azure, el servicio tiene funcionalidades intrínsecas de alta disponibilidad, redundancia y resistencia para mitigar el tiempo de inactividad de la base de datos frente a interrupciones planeadas y no planeadas, sin necesidad de configurar ningún componente adicional.

Componentes en Azure Database for MySQL

Componente Descripción
Servidor de bases de datos MySQL Azure Database for MySQL proporciona seguridad, aislamiento, medidas de seguridad para recursos y una funcionalidad de reinicio rápido para los servidores de bases de datos. Estas funcionalidades facilitan que operaciones como el escalado y la recuperación del servidor de bases de datos después de una interrupción se pueda realizar en 60-120 segundos en función de la actividad transaccional de la base de datos.
Normalmente, las modificaciones de datos en el servidor de base de datos se producen en el contexto de una transacción de base de datos. Todos los cambios en la base de datos se registran sincrónicamente como registros de escritura previa (ib_log) en Azure Storage, que está conectado al servidor de bases de datos. Durante el proceso de punto de comprobación, las páginas de datos de la memoria del servidor de bases de datos también se vacían en el almacenamiento.
Almacenamiento remoto Todos los archivos de datos físicos de MySQL y los archivos de registro se almacenan en Azure Storage, que está diseñado para almacenar tres copias de los datos en una región para garantizar la redundancia, disponibilidad y confiabilidad de los datos. La capa de almacenamiento también es independiente del servidor de bases de datos. Se puede desasociar de un servidor de base de datos con errores y asociarse de nuevo a un nuevo servidor de base de datos en 60 segundos. Además, Azure Storage supervisa continuamente el entorno en busca de errores de almacenamiento. Si se detectan daños en un bloque, se corrige automáticamente mediante la creación de una nueva copia de almacenamiento.
Puerta de enlace La puerta de enlace actúa como un proxy de base de datos, enruta todas las conexiones de cliente al servidor de base de datos.

Mitigación del tiempo de inactividad planeado

Azure Database for MySQL está diseñado para proporcionar alta disponibilidad durante las operaciones de tiempo de inactividad planeado.

view of Elastic Scaling in Azure MySQL

Estos son algunos escenarios de mantenimiento planeado:

Escenario Descripción
Escalado y reducción vertical de proceso Cuando el usuario realiza una operación de escalado o reducción vertical de procesos, se aprovisiona un nuevo servidor de base de datos con la configuración de proceso escalado. En el servidor de base de datos anterior, se permite que se finalicen los puntos de comprobación activos, se purgan las conexiones de cliente, se cancelan las transacciones no confirmadas y, a continuación, se apaga el servidor. A continuación, el almacenamiento se desasocia del servidor de base de datos anterior y se conecta al nuevo servidor de base de datos. Cuando la aplicación cliente reintenta la conexión o trata de establecer una conexión nueva, la puerta de enlace dirige la solicitud de conexión al nuevo servidor de bases de datos.
Escalado vertical del almacenamiento El escalado vertical del almacenamiento es una operación en línea y no interrumpe el servidor de base de datos.
Nueva implementación de software (Azure) Las nuevas características de implementación o corrección de errores se producen automáticamente como parte del mantenimiento planeado del servicio. Para obtener más información, consulte la documentación y consulte también el portal.
Actualizaciones de versión secundarias Azure Database for MySQL revisa automáticamente los servidores de bases de datos según la versión secundaria determinada por Azure. Se produce como parte del mantenimiento planeado del servicio. Durante el mantenimiento planeado, puede haber reinicios o conmutaciones por error del servidor de bases de datos, lo que podría dar lugar a una breve indisponibilidad de los servidores de bases de datos para los usuarios finales. Los servidores de Azure Database for MySQL se ejecutan en contenedores, por lo que los reinicios del servidor de bases de datos suelen ser rápidos y normalmente se espera que se completen en 60-120 segundos. El equipo de ingeniería supervisa cuidadosamente el evento de mantenimiento planeado completo, incluidos los reinicios del servidor. El tiempo de conmutación por error del servidor depende del tiempo de recuperación de la base de datos, lo que puede hacer que la base de datos se ponga en línea más tiempo si tiene mucha actividad transaccional en el servidor en el momento de la conmutación por error. Para evitar un tiempo de reinicio más largo, se recomienda evitar las transacciones de larga duración (cargas masivas) durante los eventos de mantenimiento planeado. Para obtener más información, consulte la documentación y consulte también el portal.

Mitigación del tiempo de inactividad no planeado

Se puede producir un tiempo de inactividad no planeado como resultado de errores imprevistos, incluidos los errores subyacentes de hardware, los problemas de red y los errores de software. Si el servidor de base de datos deja de funcionar de forma inesperada, se aprovisiona automáticamente un nuevo servidor de base de datos en 60-120 segundos. El almacenamiento remoto se asocia automáticamente al nuevo servidor de base de datos. El motor de MySQL realiza la operación de recuperación mediante WAL y archivos de base de datos, y abre el servidor de bases de datos para permitir que los clientes se conecten. Las transacciones no confirmadas se pierden y la aplicación debe volver a intentarlas. Aunque no se puede evitar un tiempo de inactividad no planeado, Azure Database for MySQL lo reduce gracias a que realiza de forma automática operaciones de recuperación en el servidor de bases de datos y en las capas de almacenamiento sin necesidad de intervención humana.

view of High Availability in Azure MySQL

Tiempo de inactividad no planeado: escenarios de error y recuperación de servicio

Estos son algunos escenarios de error y cómo Azure Database for MySQL se recupera automáticamente:

Escenario Recuperación automática
Error de servidor de bases de datos Si el servidor de base de datos está inactivo debido a un error de hardware subyacente, se quitan las conexiones activas y se anulan las transacciones inactivas. Se implementa automáticamente un nuevo servidor de base de datos y el almacenamiento de datos remotos se adjunta al nuevo servidor de base de datos. Una vez completada la recuperación de la base de datos, los clientes pueden conectarse al nuevo servidor de base de datos a través de la puerta de enlace.

Las aplicaciones que usan bases de datos de MySQL se deben crear de forma que detecten y reintenten las conexiones eliminadas y las transacciones erróneas. Cuando la aplicación vuelve a intentarlo, la puerta de enlace redirige de forma transparente la conexión al servidor de base de datos recién creado.
Error de almacenamiento Las aplicaciones no verán ningún impacto por los problemas relacionados con el almacenamiento, como un error de disco o un daño de bloque físico. A medida que los datos se almacenan en tres copias, el almacenamiento que se conserva proporciona la copia de los datos. Los daños en bloques se corrigen automáticamente. Si se pierde una copia de los datos, se crea automáticamente una nueva.

Estos son algunos escenarios de error que requieren de la acciones del usuario para recuperarse:

Escenario Plan de recuperación
Error de región Un error en una región es un evento poco habitual. Sin embargo, si necesita protección ante un error de región, puede configurar una o varias réplicas de lectura en otras regiones para la recuperación ante desastres (DR). (Consulte este artículo sobre cómo crear y administrar réplicas de lectura para más información). En caso de que se produzca un error de nivel de región, puede promover manualmente la réplica de lectura configurada en la otra región para que sea el servidor de base de datos de producción.
Errores de usuario o lógicos La recuperación de los errores de usuario, como las tablas eliminadas accidentalmente o los datos actualizados incorrectamente, implica la realización de una recuperación a un momento dado (PITR), de modo que se restauran y recuperan los datos hasta el momento justo antes de que se produjera el error.

Si quiere restaurar únicamente un subconjunto de bases de datos o tablas específicas en lugar de todas las bases de datos del servidor de bases de datos, puede restaurar el servidor de base de datos en una nueva instancia, exportar las tablas mediante mysqldump y usar restore para restaurar esas tablas en la base de datos.

Resumen

Azure Database for MySQL ofrece una funcionalidad de reinicio rápido de servidores de bases de datos, almacenamiento redundante y enrutamiento eficaz desde la puerta de enlace. Para proteger los datos de forma adicional, puede configurar las copias de seguridad para que se repliquen geográficamente, así como implementar una o varias réplicas de lectura en otras regiones. Con funcionalidades de alta disponibilidad intrínsecas, Azure Database for MySQL protege las bases de datos de las interrupciones más comunes y ofrece un Acuerdo de Nivel de Servicio con tiempo de actividad del 99,99 % con respaldo económico. Todas estas funcionalidades de disponibilidad y confiabilidad permiten que Azure sea la plataforma ideal para ejecutar aplicaciones críticas.

Pasos siguientes