Introducción a la continuidad empresarial con Azure Database for MySQL: servidor flexible
Azure Database for MySQL: servidor flexible habilita capacidades de continuidad empresarial que protegen las bases de datos en caso de una interrupción, ya sea planeada o no. Características como las copias de seguridad automatizadas y la alta disponibilidad abordan distintos niveles de protección ante errores con diferentes tiempos de recuperación y riesgos de pérdida de datos. Cuando diseñe la aplicación para protegerse frente a errores, debe tener en cuenta el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) de cada aplicación. El RTO es la tolerancia al tiempo de inactividad y el RPO es la tolerancia de pérdida de datos después de una interrupción del servicio de base de datos.
En la tabla siguiente se muestran las características que ofrece el servidor flexible de Azure Database for MySQL.
| Característica | Descripción | Restricciones |
|---|---|---|
| Copia de seguridad y recuperación | El servicio realiza automáticamente copias de seguridad diarias de los archivos de la base de datos y copias de seguridad continuas de los registros de transacciones. Las copias de seguridad se pueden conservar durante cualquier período entre 1 y 35 días. Puede restaurar el servidor de bases de datos a cualquier momento en el período de retención de copia de seguridad. El tiempo de recuperación depende del tamaño de los datos para restaurar y el tiempo para realizar la recuperación del registro. Consulte Copia de seguridad y restauración en Azure Database for MySQL: servidor flexible para obtener más detalles. | Datos de copia de seguridad conservados dentro de la región |
| Copia de seguridad con redundancia local | Las copias de seguridad de servicio se almacenan de forma automática y segura en un almacenamiento con redundancia local dentro de una región y en la misma zona de disponibilidad. Las copias de seguridad con redundancia local replican los archivos de datos de la copia de seguridad del servidor tres veces dentro de una única ubicación física de la región primaria. El almacenamiento de copia de seguridad con redundancia local proporciona una durabilidad mínima del 99,999999999 % (once nueves) de los objetos a lo largo de un año determinado. Consulte Copia de seguridad y restauración en Azure Database for MySQL: servidor flexible para obtener más detalles. | Aplicable en todas las regiones |
| Copia de seguridad con redundancia de zona | A partir de mediados de diciembre de 2024, las copias de seguridad del servicio se pueden configurar como con redundancia de zona en el momento de la creación. Al habilitar la redundancia de zona, se replicará la cuenta de almacenamiento de forma sincrónica en tres zonas de disponibilidad de Azure de la región primaria. Cada zona de disponibilidad es una ubicación física individual con alimentación, refrigeración y redes independientes. ZRS proporciona a los recursos de almacenamiento una durabilidad de al menos el 99,9999999999 % (doce nueves) durante un año determinado. Esta configuración permitirá la recuperación fluida durante las interrupciones zonales. | Solo se admitirá en el nivel de proceso Crítico para la empresa a mediados de diciembre de 2024. Está disponible únicamente en regiones con varias zonas. |
| Copia de seguridad con redundancia geográfica | Las copias de seguridad de servicio se pueden configurar con redundancia geográfica en el momento de la creación. Al habilitar la redundancia geográfica, se replican los archivos de datos de copia de seguridad del servidor en la región primaria emparejada para proporcionar resistencia regional. El almacenamiento de copia de seguridad con redundancia geográfica proporciona una durabilidad mínima del 99,99999999999999 % (16 nueves) de los objetos a lo largo de un año determinado. Consulte Copia de seguridad y restauración en Azure Database for MySQL: servidor flexible para obtener más detalles. | Disponible en todas las regiones emparejadas de Azure. |
| Alta disponibilidad con redundancia de zona | El servicio se puede implementar en modo de alta disponibilidad, que implementa los servidores principal y en espera en dos zonas de disponibilidad diferentes dentro de una región. La alta disponibilidad con redundancia de zona protege frente a errores de nivel de zona 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. Los datos del servidor principal se replican de forma sincrónica en la réplica en espera. Durante cualquier evento de tiempo de inactividad, el servidor de bases de datos se conmuta por error automáticamente en la réplica en espera. Consulte Conceptos de alta disponibilidad en Azure Database for MySQL: servidor flexible para obtener más detalles. | Se admite en niveles de proceso de uso general y Crítico para la empresa. Está disponible únicamente en regiones con varias zonas. |
| Recursos compartidos de archivos Premium | Los archivos de base de datos se almacenan en recursos compartidos Premium de Azure de gran durabilidad y confiabilidad que proporcionan redundancia de datos con tres copias de réplica almacenadas en una zona de disponibilidad con capacidades de recuperación de datos automáticas. Vea Recursos compartidos de archivos Premium para obtener más detalles. | Datos almacenados en una zona de disponibilidad |
Mitigación del tiempo de inactividad planeado
Estos son algunos escenarios de mantenimiento planeado que conllevan tiempo de inactividad:
| Escenario | Process |
|---|---|
| Escalado de proceso (usuario) | Cuando se realiza una operación de escalado de proceso, se aprovisiona un nuevo servidor flexible con la configuración del proceso escalado. En el servidor de bases de datos existente, se permite que se completen los puntos de comprobación activos, se purgan las conexiones de cliente, se cancelan las transacciones sin confirmar y después se cierra. A continuación, el almacenamiento se adjunta al nuevo servidor y se inicia la base de datos, que realiza la recuperación si es necesario antes de aceptar conexiones de cliente. |
| Nueva implementación de software (Azure) | La implementación de nuevas características o correcciones de errores se produce automáticamente como parte del mantenimiento planeado del servicio, y es posible programar cuándo se realizan esas actividades. Para obtener más información, vea la documentación y el portal. |
| Actualizaciones de versiones secundarias (Azure) | El servidor flexible de Azure Database for MySQL aplica revisiones automáticas a los servidores de bases de datos a la versión secundaria determinada por Azure. Se produce como parte del mantenimiento planeado del servicio. Esto provocaría un breve tiempo de inactividad en términos de segundos y el servidor de base de datos se reiniciará automáticamente con la nueva versión secundaria. Para obtener más información, vea la documentación y el portal. |
Cuando el servidor flexible se configura con alta disponibilidad con redundancia de zona, primero realiza operaciones en el servidor en espera y, después, en el principal sin conmutación por error. Consulte Conceptos de alta disponibilidad en Azure Database for MySQL: servidor flexible para obtener más detalles.
Mitigación del tiempo de inactividad no planeado
Se pueden producir tiempos de inactividad no planeados como resultado de errores imprevistos, incluidos errores subyacentes de hardware, problemas de red y errores de software. Si el servidor de bases de datos deja de funcionar de forma inesperada, en caso de estar configurado con alta disponibilidad (HA), se activa la réplica en espera. Si no es así, se aprovisiona automáticamente un nuevo servidor de bases de datos. Aunque no es posible evitar un tiempo de inactividad no planeado, el servidor flexible lo reduce gracias a las operaciones de recuperación automáticas tanto en el servidor de bases de datos como en las capas de almacenamiento sin necesidad de intervención humana.
Tiempo de inactividad no planeado: escenarios de error y recuperación de servicio
Estos son algunos escenarios de error no planeados y el proceso de recuperación:
| Escenario | Proceso de recuperación (sin alta disponibilidad) | Proceso de recuperación (con HA) |
|---|---|---|
| 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. Azure intenta reiniciar el servidor de bases de datos. Si lo hace correctamente, se realizará la recuperación de la base de datos. Si se produce un error en el reinicio, se intenta reiniciar el servidor de bases de datos en otro nodo físico. El tiempo de recuperación (RTO) depende de varios factores, incluida la actividad en el momento del error, como una transacción grande y la cantidad de recuperación que se realizará durante el proceso de inicio del servidor de bases de datos. El RPO es cero, ya que no se espera pérdida de datos para las transacciones confirmadas. 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 vuelva a intentarlo, las conexiones se dirigirán al servidor de bases de datos recién creado. Otras opciones disponibles son la restauración desde la copia de seguridad. Puede usar la recuperación a un momento dado o la restauración geográfica desde una región emparejada. Recuperación a un momento dado : RTO: Varies, RPO=0sec Restauración geográfica: RTO: Varies RPO 1 h. También puede usar la réplica de lectura como solución de recuperación ante desastres. Puede detener la replicación, lo que hace que la réplica de lectura y escritura (independiente y, a continuación, redirija el tráfico de la aplicación a esta base de datos). El RTO en la mayoría de los casos es de unos minutos y el RPO < 1 h. RTO y RPO pueden ser mucho mayores en algunos casos, en función de varios factores, incluida la latencia entre sitios, la cantidad de datos que se van a transmitir y, importantemente, la carga de trabajo de escritura de la base de datos principal. |
Si se detectan errores del servidor de bases de datos o errores no recuperables, se activa el servidor de bases de datos en espera, lo que reduce el tiempo de inactividad. Consulte la página de conceptos de alta disponibilidad para obtener más detalles. Se espera que el RTO oscile entre 60 y 120 s, con RPO = 0. Nota: Aquí también se aplican las opciones para el proceso de recuperación [no alta disponibilidad]. |
| Error de almacenamiento | Los problemas relacionados con el almacenamiento, como un error de disco o un daño de bloque físico, no afectarán a las aplicaciones. Puesto que los datos se almacenan en tres copias, el almacenamiento sobreviviente 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. En un escenario poco frecuente o en el peor de los casos, si todas las copias están dañadas, se puede usar la restauración desde Restauración geográfica (región emparejada). El RPO sería de 1 hora y el RTO variaría. También puede usar la réplica de lectura como solución de recuperación ante desastres, como se ha detallado anteriormente. |
En este escenario, las opciones son las mismas que para el proceso de recuperación [sin alta disponibilidad]. |
| 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. Los recursos de servidor flexible eliminados se pueden recuperar en un plazo de cinco días a partir del momento de la eliminación del servidor. Para obtener una guía detallada sobre cómo restaurar un servidor eliminado, [vea los pasos documentados] (../flexible-server/how-to-restore-dropped-server.md). Para proteger los recursos del servidor después de la implementación frente a eliminaciones accidentales o cambios inesperados, los administradores pueden usar los bloqueos de administración. |
Estos errores de usuario no están protegidos con alta disponibilidad, ya que todas las operaciones de usuario se replican también en el servidor en espera. En este escenario, las opciones son las mismas que para el proceso de recuperación [sin alta disponibilidad] |
| Error de zona de disponibilidad | Aunque es un evento muy poco frecuente, si desea realizar la recuperación de un error de nivel de zona, puede realizar la restauración geográfica desde a una región emparejada. El RPO sería de 1 hora y el RTO variaría. También puede usar la réplica de lectura como solución de recuperación ante desastres mediante la creación de una réplica en otra zona de disponibilidad. RTO\RPO es como lo que se ha detallado anteriormente. |
Si ha habilitado la alta disponibilidad con redundancia de zona, el servidor flexible realiza la conmutación automática por error al sitio en espera. Consulte Conceptos de alta disponibilidad en Azure Database for MySQL: servidor flexible para obtener más detalles. Se espera que el RTO oscile entre 60 y 120 s, con RPO = 0. Otras opciones disponibles son la restauración desde la copia de seguridad. Puede usar la recuperación a un momento dado o la restauración geográfica desde una región emparejada. Recuperación a un momento dado : RTO: Varies, RPO=0 sec Restauración geográfica: RTO: Varies RPO 1 h Nota: Si tiene habilitada la misma alta disponibilidad de zona, las opciones son las mismas que para el proceso de recuperación [no alta disponibilidad]. |
| Error de región | Aunque es un evento muy poco frecuente, si desea recuperarse de un error de nivel de región, puede realizar la recuperación de la base de datos mediante la creación de un servidor con la copia de seguridad con redundancia geográfica más reciente disponible en la misma suscripción para obtener los datos más recientes. Se implementa un nuevo servidor flexible en la región seleccionada. El tiempo necesario para la restauración dependerá de la copia de seguridad anterior y del número de registros de transacciones que se vayan a recuperar. En la mayoría de los casos, el RPO sería de 1 hora y el RTO variaría. | En este escenario, las opciones son las mismas que para el proceso de recuperación [sin alta disponibilidad]. |
Requisitos y limitaciones
Residencia de datos en la región
De manera predeterminada, el servidor flexible de Azure Database for MySQL no mueve ni almacena los datos de los clientes fuera de la región en la que se implementa. Sin embargo, los clientes pueden optar por habilitar copias de seguridad con redundancia geográfica o configurar la replicación entre regiones para almacenar datos en otra región.