Partekatu honen bidez:

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

  • Artikulua

Importante

Azure Database for MariaDB está en proceso de retirada. Le recomendamos que realice la migración a Azure Database for MySQL. Para más información sobre la migración a Azure Database for MySQL, consulte ¿Qué está ocurriendo 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. Sepa qué hacer en caso de que un error del usuario o de la aplicación afecte a la integridad de los datos, se produzca una interrupción en una región de Azure o su aplicación requiera 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): el máximo tiempo aceptable antes de que la aplicación se recupere por completo tras una interrupción.
  • 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 perder cuando se está recuperando de una interrupción.

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 posibilidad de iniciar la restauración geográfica y la implementación de 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 característica de restauración geográfica, Azure DB for MariaDB crea un servidor con los datos de copia de seguridad que se replican desde otra región. El tiempo total que se tarda en la restauración y la recuperación 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. En caso de 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, sobre todo, de la carga de trabajo de escritura del servidor principal. Las cargas de trabajo de escritura intensivas pueden generar retrasos significativos.

Debido a la naturaleza asincrónica de la replicación que se usa para las réplicas de lectura, las réplicas de lectura no deben considerarse una solución de alta disponibilidad. Los retrasos más altos pueden significar un RTO y RPO más altos. Solo en el caso de las cargas de trabajo en las que el retraso sigue siendo poco en las horas de poca y mucha actividad de la carga de trabajo, las réplicas de lectura pueden actuar como una alternativa de alta disponibilidad. De lo contrario, las réplicas de solo lectura están pensadas para escala de lectura verdadera en cargas de trabajo con alta demanda de lectura 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 Básico Uso general Memoria optimizada
Restauración a un momento dado a partir de una copia de seguridad Cualquier punto de restauración dentro del período de retención
El RTO varía
El RPO es inferior a 15 minutos		 Cualquier punto de restauración dentro del período de retención
El RTO varía
El RPO es inferior a 15 minutos		 Cualquier punto de restauración dentro del período de retención
El 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 El RTO varía
El RPO es superior a 24 horas		 El RTO varía
El RPO es superior a 24 horas
Réplicas de lectura El RTO es de unos minutos
El RPO es inferior a 5 minutos		 El RTO es de unos minutos
El RPO es inferior a 5 minutos		 El RTO es de unos minutos
El RPO es inferior a 5 minutos

El 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 la carga de trabajo de escritura de la base de datos principal.

Recuperación de un servidor tras un error del usuario o de la 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 de forma involuntaria algunos datos, una tabla importante o, incluso, una base de datos entera. Una aplicación podría sobrescribir accidentalmente datos correctos por otros no válidos debido a un defecto en esta.

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 incluido en el período de retención de la copia de seguridad que configuró para el servidor. Después de restaurar los datos en el nuevo servidor, puede reemplazar el servidor original por el recién restaurado o copiar los datos necesarios del servidor restaurado en el servidor original.

Importante

Solo puede restaurar servidores eliminados en cinco días de 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 de la interrupción de un centro de datos regional de Azure

Aunque sea poco habitual, en un centro de datos de Azure se pueden producir interrupciones. Cuando esto ocurre, provoca también una interrupción de la actividad que podría alargarse unos minutos o incluso horas.

Una opción consiste en esperar a que el servidor vuelva a estar en línea cuando termine la interrupción del centro de datos. Cuando el centro de datos tiene una interrupción, no sabe cuánto tiempo puede durar. Así que esta opción es válida para aquellas aplicaciones que se pueden permitir tener el servidor sin conexión durante algún tiempo (por ejemplo, las aplicaciones de un entorno de producción).

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. Se puede acceder a estas copias de seguridad incluso cuando la región en la que se hospeda el servidor está sin conexión. Puede realizar la restauración a partir de estas copias de seguridad en cualquier otra región y volver a poner en línea el servidor. Aprenda más 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 se ha aprovisionado 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, restáurela en 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 el planeamiento de la continuidad empresarial y recuperación ante desastres. Las réplicas de lectura se actualizan de manera asincrónica mediante la tecnología de replicación de registros binarios de MySQL. Descubra más sobre las réplicas de lectura, las regiones disponibles y la conmutación por error en el artículo sobre los conceptos de las réplicas de lectura.

Preguntas más frecuentes

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

De manera predeterminada, Azure Database for MariaDB no mueve ni almacena los datos de los clientes fuera de la región en la que se han implementado. Sin embargo, los clientes tienen la opción de habilitar las copias de seguridad con redundancia geográfica o crear réplicas de lectura entre regiones para almacenar los datos en otra región.

Pasos siguientes