Introducción a la continuidad empresarial con Azure Database for MariaDB

  • Artículo

Importante

Azure Database for MariaDB está en proceso de retirada. Se recomienda encarecidamente migrar a Azure Database for MySQL. Para más información sobre la migración a Azure Database for MySQL, consulte ¿Qué ocurre con Azure Database for MariaDB?.

En este artículo se describen las funcionalidades de continuidad empresarial y recuperación ante desastres que proporciona Azure Database for MariaDB. Conozca más información sobre opciones para recuperarse de eventos de interrupción que podrían provocar la pérdida de información o que su base de datos y aplicación dejen de estar disponibles. Obtenga información sobre qué hacer cuando un error de usuario o un error de aplicación afecta a la integridad de los datos, una región de Azure tiene una interrupción o la aplicación necesita mantenimiento.

Características para la continuidad empresarial

A medida que desarrolle su plan de continuidad empresarial, debe comprender lo siguiente:

  • Objetivo de tiempo de recuperación (RTO): tiempo máximo aceptable antes de que la aplicación se recupere completamente después de un evento disruptivo.
  • Objetivo de punto de recuperación (RPO): la cantidad máxima de actualizaciones de datos recientes (intervalo de tiempo) que la aplicación puede tolerar la pérdida cuando se está recuperando después de un evento disruptivo.

Azure Database for MariaDB proporciona características de continuidad empresarial y recuperación ante desastres que incluyen copias de seguridad con redundancia geográfica con la capacidad de iniciar la restauración geográfica e implementar réplicas de lectura en otra región. Cada una de ellas posee distintas características que abarcan los conceptos de tiempo de recuperación y pérdida de datos potencial.

Con la restauración geográfica, Azure Database for MariaDB crea un nuevo servidor mediante los datos de copia de seguridad que se replican desde otra región. El tiempo total para restaurar y recuperar depende del tamaño de la base de datos y de la cantidad de datos de registro que se van a recuperar. El tiempo total para establecer el servidor varía de unos minutos a pocas horas.

Con las réplicas de lectura, los registros de transacciones de la base de datos principal se transmiten de forma asincrónica a una réplica. Si hay una interrupción de la base de datos principal debido a un error de nivel de zona o de región, la conmutación por error a la réplica proporciona un RTO más corto y una pérdida de datos reducida.

Nota:

El retraso entre la base de datos principal y la réplica depende de la latencia entre los sitios, la cantidad de datos que se van a transmitir y (lo más importante) la carga de trabajo de escritura del servidor principal. Las cargas de trabajo de escritura intensiva pueden generar un retraso significativo.

Debido a la naturaleza asincrónica de la replicación que se usa para réplicas de lectura, no considere que las réplicas de lectura sean una solución de alta disponibilidad. Los retrasos más altos pueden significar un RTO y RPO más altos. Las réplicas de lectura pueden actuar como una alternativa de alta disponibilidad solo para las cargas de trabajo en las que el retraso permanece más pequeño a través de las horas punta y fuera del pico. De lo contrario, las réplicas de lectura están diseñadas para una escala de lectura verdadera para cargas de trabajo de lectura intensiva y para escenarios de recuperación ante desastres.

En la tabla siguiente se comparan el RTO y el RPO en un escenario de carga de trabajo típica:

Funcionalidad Basic Uso general Memoria optimizada
Restauración a un momento dado desde la copia de seguridad Cualquier punto de restauración dentro del período de retención
RTO varía
El RPO es inferior a 15 minutos		 Cualquier punto de restauración dentro del período de retención
RTO varía
El RPO es inferior a 15 minutos		 Cualquier punto de restauración dentro del período de retención
RTO varía
El RPO es inferior a 15 minutos
Restauración geográfica de las copias de seguridad con replicación geográfica No compatible RTO varía
El RPO es mayor que 24 horas		 RTO varía
El RPO es mayor que 24 horas
Réplicas de lectura RTO es minutos
El RPO es inferior a 5 minutos		 RTO es minutos
El RPO es inferior a 5 minutos		 RTO es minutos
El RPO es inferior a 5 minutos

RTO y RPO pueden ser mucho mayores en algunos casos, en función de factores como la latencia entre sitios, la cantidad de datos que se van a transmitir y la carga de trabajo de escritura de la base de datos principal.

Recuperación de un servidor después de un error de usuario o aplicación

Puede usar las copias de seguridad del servicio para recuperar un servidor a partir de diversos eventos de interrupción. Por ejemplo, un usuario podría eliminar accidentalmente algunos datos, quitar accidentalmente una tabla importante o incluso quitar una base de datos completa. Una aplicación podría sobrescribir accidentalmente datos buenos con datos incorrectos debido a un defecto de la aplicación.

Puede realizar una restauración a un momento dado para crear una copia del servidor en un momento dado conocido correcto. Este momento dado debe estar dentro del período de retención de copia de seguridad que configuró para el servidor. Una vez restaurados los datos en el nuevo servidor, puede reemplazar el servidor original por el servidor recién restaurado o copiar los datos necesarios del servidor restaurado en el servidor original.

Importante

Puede restaurar los servidores eliminados solo en un plazo de cinco días después de la eliminación. Después de cinco días, se eliminan las copias de seguridad. Solo puede acceder a la copia de seguridad de la base de datos y restaurarla desde la suscripción de Azure que hospeda el servidor. Para restaurar un servidor eliminado, consulte los pasos documentados. Para ayudar a proteger los recursos del servidor frente a eliminaciones accidentales o cambios inesperados después de la implementación, los administradores pueden usar los bloqueos de administración.

Recuperación desde una interrupción del centro de datos regional de Azure

Aunque es poco frecuente, un centro de datos de Azure puede tener una interrupción. Cuando se produce una interrupción, provoca una interrupción empresarial que puede durar solo unos minutos, pero podría durar durante horas.

Una opción es esperar a que el servidor vuelva a estar en línea cuando finalice la interrupción del centro de datos. Cuando el centro de datos tiene una interrupción, no sabe cuánto tiempo puede durar la interrupción. Por lo tanto, esta opción solo funciona para las aplicaciones que pueden permitirse tener el servidor sin conexión durante algún tiempo (por ejemplo, un entorno de desarrollo).

Geo-restore

La característica de restauración geográfica restaura el servidor mediante copias de seguridad con redundancia geográfica. Las copias de seguridad se hospedan en la región emparejada del servidor. Estas copias de seguridad son accesibles incluso cuando la región donde se hospeda el servidor está sin conexión. Puede restaurar desde estas copias de seguridad a cualquier otra región y, a continuación, volver a poner el servidor en línea. Obtenga más información sobre la restauración geográfica en el artículo sobre los conceptos de copia de seguridad y restauración.

Importante

La restauración geográfica solo es posible si aprovisionó el servidor con almacenamiento de copia de seguridad con redundancia geográfica. Si desea cambiar de copias de seguridad con redundancia local a con redundancia geográfica para un servidor existente, debe generar una copia de seguridad del servidor existente mediante mysqldump. A continuación, restaure a un servidor recién creado configurado con copias de seguridad con redundancia geográfica.

Réplicas de lectura entre regiones

Puede usar réplicas de lectura entre regiones para mejorar la planificación de la continuidad empresarial y la recuperación ante desastres. Las réplicas de lectura se actualizan de forma asincrónica mediante la tecnología de replicación de MySQL para los registros binarios. Obtenga más información sobre las réplicas de lectura, las regiones disponibles y cómo conmutar por error en el artículo sobre los conceptos de réplica de lectura.

Preguntas más frecuentes

¿Dónde almacena los datos de los clientes Azure Database for MariaDB?

De forma predeterminada, Azure Database for MariaDB no mueve ni almacena los datos de los clientes fuera de la región donde se implementa. Sin embargo, opcionalmente, puede optar por habilitar copias de seguridad con redundancia geográfica o crear réplicas de lectura entre regiones para almacenar datos en otra región.

Pasos siguientes