Comparación de las opciones de continuidad empresarial y recuperación ante desastres
El servidor flexible de Azure Database for MySQL proporciona características de continuidad empresarial para proteger la base de datos en caso de interrupciones planeadas o no planeadas. Para solucionar diferentes tipos de interrupciones, puede aplicar distintos niveles de protección de errores con diferentes tiempos de recuperación o riesgo de pérdida de datos.
Ejemplos de tiempo de inactividad
A continuación se muestran algunos escenarios de ejemplo para el tiempo de inactividad planeado y no planeado.
Escenarios de tiempo de inactividad planeado
Los dos escenarios de tiempo de inactividad planeado más comunes son los de escalado de proceso iniciado por el usuario y de mantenimiento programado realizado por Azure.
Al realizar una operación de escalado de proceso, Azure aprovisiona un nuevo servidor flexible de MySQL con la configuración de proceso solicitada. El servidor existente permite que se completen los puntos de control activos, purga las conexiones existentes, cancela las transacciones no confirmadas y, después, el servidor existente se apaga. En este momento, Azure adjunta el almacenamiento del servidor existente al nuevo servidor e inicia la base de datos. Después, la base de datos realiza cualquier recuperación necesaria antes de continuar aceptando conexiones de cliente.
Las nuevas características y correcciones de errores se producen automáticamente como parte del mantenimiento planeado del servicio. Las revisiones de actualización de versiones secundarias también se aplican durante el mantenimiento planeado, lo que conlleva unos segundos de tiempo de inactividad. Puede programar esas actividades como se describe en la sección siguiente, "Ventanas de tiempo de inactividad y mantenimiento programado".
Tiempo de inactividad no planeado
La base de datos se puede desconectar inesperadamente por varias razones, como las siguientes:
- Error de hardware de la base de datos.
- Error de la unidad de almacenamiento.
- Errores de la aplicación o el usuario (por ejemplo, eliminación accidental de tablas).
- Errores de zona de disponibilidad y región.
Si la alta disponibilidad (HA) no está habilitada, Azure intenta la recuperación con la copia de datos perdidos, el reinicio del servidor o incluso el inicio del servidor en otro nodo físico. La habilitación de la alta disponibilidad puede reducir o incluso eliminar estos tipos de tiempo de inactividad, como se describe en la sección siguiente.
Alta disponibilidad
El servidor flexible de Azure Database for MySQL ofrece alta disponibilidad con conmutación automática por error, lo que proporciona una solución diseñada para no perder datos confirmados y evitar que la base de datos sea un único punto de error. Cuando se ha configurado la alta disponibilidad, el servidor flexible de MySQL aprovisiona y administra de manera automática una réplica en espera.
Hay dos tipos de alta disponibilidad con diferencias de tolerancia a errores y desventajas de latencia: redundancia de zona y misma zona.
Alta disponibilidad con redundancia de zona
La alta disponibilidad con redundancia de zona proporciona redundancia en varias zonas de disponibilidad, lo que ofrece el mayor nivel de disponibilidad con la capacidad de recuperación incluso si toda una zona deja de funcionar. El uso de una configuración de alta disponibilidad con redundancia de zona presenta una latencia adicional, por lo que debe asegurarse de determinar si esto es aceptable para la aplicación. Además, para usar una configuración de alta disponibilidad con redundancia de zona también es necesario que las aplicaciones cliente de base de datos tengan redundancia de zona para asegurarse de que las operaciones generales continúan.
Alta disponibilidad en la misma zona
En una configuración de alta disponibilidad de la misma zona, los servidores principales y en espera residen en la misma zona de disponibilidad, lo que minimiza la latencia. Aunque en algunos casos de uso puede ser necesaria una latencia baja, con una configuración de alta disponibilidad de la misma zona, si la zona de disponibilidad deja de funcionar, el tiempo de inactividad resultante será mayor a medida que el servidor flexible de MySQL se recupera.
A diferencia de la alta disponibilidad con redundancia de zona, la alta disponibilidad de la misma zona está disponible en todas las regiones que admiten el servidor flexible de Azure Database for MySQL.
Copia de seguridad y restauración
Las copias de seguridad del servidor son un componente fundamental de cualquier estrategia de continuidad empresarial. El servidor flexible de Azure Database for MySQL crea automáticamente copias de seguridad y las almacena de forma segura en el almacenamiento con redundancia local en la región en la que se hospeda la base de datos. Puede usar estas copias de seguridad para restaurar la base de datos a un momento dado específico, en caso de errores o daños en los datos (por ejemplo, un error de la aplicación o de desarrollo).
Hay dos tipos de copias de seguridad. Con las copias de seguridad automatizadas, el servidor flexible de MySQL toma instantáneas de los archivos de datos de base de datos, así como de los registros de transacciones asociados. Las copias de seguridad automatizadas de instantáneas se realizan una vez al día y las copias de seguridad del registro de transacciones cada cinco minutos. Si se produce un error en la copia de seguridad, el servidor realiza reintentos cada 20 minutos hasta que la copia de seguridad se realiza correctamente.
Con las copias de seguridad a petición, puede crear una copia de seguridad de la base de datos en cualquier momento. Con ambos tipos de copias de seguridad, los archivos de copia de seguridad se conservan durante siete días de manera predeterminada. Pero en función de las necesidades empresariales, puede configurar el valor del período de retención de 1 a 35 días.
Puede conservar las copias de seguridad durante hasta 10 años mediante la característica de retención a largo plazo, actualmente en versión preliminar pública. La solución de copia de seguridad a largo plazo se puede usar por separado o además de las copias de seguridad automatizadas de Azure Database for MySQL. Las copias de seguridad a largo plazo se pueden realizar según una programación controlada por el cliente o a petición. Las copias de seguridad se almacenan en cuentas de almacenamiento administradas de Azure Backup, en dominios de error y seguridad independientes.
Además de realizar copias de seguridad de la base de datos, puede exportar archivos de copia de seguridad a Azure Blob Storage, que después puede usar para migraciones, recuperación de datos o archivado. Las exportaciones a petición se encuentran actualmente en versión preliminar pública y solo están disponibles en regiones de nube pública.
Para almacenar los archivos de copia de seguridad, puede seleccionar entre varias opciones de almacenamiento:
Con el almacenamiento con redundancia local (mismo centro de datos, misma zona), los archivos de copia de seguridad se almacenan en el mismo centro de datos que la base de datos. Esta opción proporciona once 9 (99,999999999 %) de durabilidad para los objetos de copia de seguridad durante un año. De manera predeterminada, los servidores sin alta disponibilidad o con alta disponibilidad de la misma zona usan almacenamiento con redundancia local.
Con el almacenamiento concopia de seguridad con redundancia de zona (otra zona, misma región), los archivos de copia de seguridad se almacenan en la zona de disponibilidad del servidor y se replican en otra zona de disponibilidad de la misma región. Esta opción proporciona doce 9 (99 9999999999 %) de durabilidad durante un año determinado. El almacenamiento con redundancia de zona es importante para la alta disponibilidad con redundancia de zona y es necesario si los datos deben permanecer dentro de una sola región.
Con el almacenamiento de copia de seguridad con redundancia geográfica (regiones diferentes), los archivos de copia de seguridad se almacenan en la región del servidor y, después, se replican en otra región emparejada geográficamente. Esta opción proporciona 16 9 (99,99999999999999 %) de durabilidad durante un año determinado. El almacenamiento con redundancia geográfica solo se admite en regiones emparejadas de Azure.
Nota: Con el servidor flexible de Azure Database for MySQL, el espacio de copia de seguridad hasta el 100 % del espacio de almacenamiento aprovisionado está disponible sin ningún cargo adicional. El almacenamiento adicional se cobra en GB al mes. Para más información, vea la documentación de precios.
Después de realizar una copia de seguridad, puede restaurarla en un nuevo servidor flexible de MySQL. Puede seleccionar las tres maneras de realizar la copia de seguridad: seleccionar manualmente una copia de seguridad completa, seleccionar automáticamente el punto de restauración más reciente o seleccionar automáticamente el punto de restauración más rápido. Si tiene copias de seguridad con redundancia geográfica, también puede restaurar a la región emparejada (la región cruzada).
Ventanas de tiempo de inactividad y mantenimiento programado
Se necesita mantenimiento periódico para mantener el servidor administrado estable, seguro y actualizado. Durante las ventanas de mantenimiento, el servicio recibe implementaciones de nuevas características, actualizaciones y revisiones. Normalmente, las ventanas de mantenimiento se programan para que se produzcan al menos cada 30 días, pero las revisiones de seguridad críticas se aplican a veces en un plazo de siete días o menos.
Puede elegir una programación administrada por el sistema o definir una programación personalizada para cada servidor flexible de MySQL en la suscripción de Azure.
Puede recibir notificaciones de mantenimiento programadas de varias maneras. Las notificaciones se pueden:
- Enviar por correo electrónico a una dirección específica o a un rol de Azure Resource Manager.
- Enviar mediante mensaje de texto (SMS).
- Insertar como una notificación de aplicación de Azure.
- Entregar mediante un mensaje de voz.
Ventanas de mantenimiento personalizadas
De manera predeterminada, con una programación administrada por el sistema, el sistema elige una ventana de una hora entre las 23:00 y las 7:00 en la zona horaria de la región horaria del servidor flexible de MySQL. Con una programación personalizada, puede especificar la ventana de mantenimiento del servidor y elegir el día de la semana y una hora.
Mantenimiento de tiempo de inactividad casi inexistente para servidores de alta disponibilidad (versión preliminar pública)
Los servidores habilitados para alta disponibilidad se benefician del mantenimiento de inactividad casi inexistente, una nueva característica que reduce considerablemente el tiempo de inactividad del mantenimiento. El tiempo de inactividad esperado es de entre 40 y 60 segundos. El mantenimiento de tiempo de inactividad casi inexistente es fundamental para las aplicaciones con requisitos de alta disponibilidad, en las que se necesitan interrupciones mínimas de la conectividad de la base de datos.
Mantenimiento de reprogramación (versión preliminar pública)
Puede volver a programar el mantenimiento cuando use los niveles de servicio De uso general o Crítico para la empresa. En la sección de mantenimiento de Azure Portal, puede volver a programar el siguiente mantenimiento programado a otra fecha y hora. También puede iniciar el mantenimiento a petición si selecciona Volver a programar Ahora.