Migración de MySQL local a Azure Database for MySQL: continuidad empresarial y recuperación ante desastres (BCDR)
Garantizar la continuidad empresarial y la recuperación ante desastres (BCDR) es fundamental para migrar bases de datos MySQL desde entornos locales a Azure Database for MySQL. En este artículo se describen las estrategias y los procedimientos recomendados para mantener operaciones ininterrumpidas y proteger los datos durante y después de la migración. Mediante el uso de las sólidas funcionalidades de BCDR de Azure, puede minimizar el tiempo de inactividad, protegerse frente a la pérdida de datos y garantizar una recuperación rápida durante un desastre. En esta guía se proporciona la información necesaria para desarrollar un plan completo de BCDR, abordar posibles riesgos y usar las características avanzadas de Azure para mejorar la resistencia y la confiabilidad. Tanto si tiene como objetivo mejorar las funcionalidades de recuperación ante desastres o garantizar la disponibilidad continua, en este artículo se proporcionan los conocimientos para lograr una migración segura y sin problemas.
Requisitos previos
Migración de datos de un entorno local de MySQL a Azure Database for MySQL: optimización
Copia de seguridad y restauración
Igual que sucede con cualquier sistema crítico, tener una copia de seguridad y restauración, y una estrategia de recuperación ante desastres (BCDR) es una parte importante del diseño general del sistema. Si se produce un evento imprevisto, debe tener la capacidad de restaurar los datos a un momento dado (objetivo de punto de recuperación) en un período de tiempo razonable (objetivo de tiempo de recuperación).
Backup
Azure Database for MySQL admite copias de seguridad automáticas durante siete días de manera predeterminada. Puede ser adecuado modificarlo al máximo actual de 35 días. Es importante tener en cuenta que, si el valor se cambia a 35 días, habrá cargos por cualquier almacenamiento de copia de seguridad adicional por encima del 1x del almacenamiento asignado.
Existen varias limitaciones actuales en la característica de copia de seguridad de base de datos, tal como se describe en el artículo que cuenta con los documentos Copia de seguridad y restauración en Azure Database for MySQL. Es importante comprender estas limitaciones a la hora de decidir qué estrategias adicionales se deben implementar.
Algunos elementos que se deben tener en cuenta son:
No hay acceso directo a las copias de seguridad.
Los niveles que permiten hasta 4 TB realizan una copia de seguridad completa una vez por semana, una diferencial dos veces al día y registros cada cinco minutos.
Los niveles que permiten hasta 16 TB tienen copias de seguridad basadas en instantáneas.
Nota
Algunas regiones aún no admiten el almacenamiento de hasta 16 TB.
Restauración
La redundancia (local o geográfica) debe configurarse durante la creación del servidor. Sin embargo, se puede realizar una restauración geográfica, ya que permite la modificación de estas opciones durante el proceso de restauración. Al realizar una operación de restauración, puede que se detenga temporalmente la conectividad y todas las aplicaciones estén sin funcionar durante el proceso de restauración.
Durante una restauración de base de datos, también se tienen que restaurar los elementos compatibles externos de la base de datos.
Revise el proceso de migración. Consulte Realizar tareas posteriores a la restauración para más información.
Réplicas de lectura
Las réplicas de lectura se pueden usar para aumentar el rendimiento de lectura de MySQL, mejorar el rendimiento de los usuarios regionales e implementar la recuperación ante desastres. Al crear una o varias réplicas de lectura, tenga en cuenta que se aplicarán cargos adicionales para el mismo proceso y almacenamiento que en el servidor principal.
Servidores eliminados
Si un administrador o un actor malintencionado elimina el servidor en Azure Portal o a través de métodos automatizados, también se eliminarán todas las copias de seguridad y réplicas de lectura. Es importante que se creen bloqueos de recursos en el grupo de recursos de Azure Database for MySQL para agregar a las instancias una capa adicional de prevención ante eliminaciones.
Error regional
Aunque es poco frecuente, si se produce un error regional, se pueden usar las copias de seguridad con redundancia geográfica o una réplica de lectura para volver a ejecutar las cargas de trabajo de datos. Es mejor tener la replicación geográfica y una réplica de lectura disponibles para conseguir la mejor protección frente a errores regionales inesperados.
Nota
Tenga en cuenta que el cambio de la región del servidor de base de datos también significa que el punto de conexión cambiará y que las configuraciones de la aplicación tendrán que actualizarse en consecuencia.
Equilibradores de carga
Si la aplicación está formada por muchas instancias diferentes de todo el mundo, es posible que no sea factible actualizar todos los clientes. Use una instancia de Azure Load Balancer o Application Gateway para implementar una funcionalidad de conmutación por error sin problemas. Aunque estas opciones son útiles y ahorran tiempo, estas herramientas no son necesarias para la funcionalidad de conmutación por error regional.
Escenario de WWI
WWI quiere probar las funcionalidades de conmutación por error de las réplicas de lectura para realizar los pasos descritos a continuación.
Creación de una réplica de lectura
Abra Azure Portal.
Vaya a la instancia de Azure Database for MySQL.
En Configuración, seleccione Replicación.
Seleccione Agregar réplica.
Escriba un nombre de servidor.
Seleccione la región.
Seleccione Aceptar y espere a que se implemente la instancia. En función del tamaño de la instancia principal, es posible que tarde algún tiempo en replicarse.
Nota
Cada réplica incurre en cargos adicionales iguales a los de la instancia principal.
Conmutación por error a una réplica de lectura
Una vez creada una réplica de lectura y completado el proceso de replicación, se puede usar para la conmutación por error. La replicación se detiene durante una conmutación por error y hará que la réplica de lectura sea su propia instancia principal.
Pasos de la conmutación por error:
Abra Azure Portal.
Vaya a la instancia de Azure Database for MySQL.
En Configuración, seleccione Replicación.
Seleccione una de las réplicas de lectura.
Selección de Detener replicación. Esto interrumpe la réplica de lectura.
Modifique todas las cadenas de conexión de aplicaciones para que apunten a la nueva instancia principal.
Lista de comprobación de BCDR
Modifique la frecuencia de copia de seguridad para que cumpla con los requisitos.
Configure réplicas de lectura para cargas de trabajo de lectura intensiva y conmutaciones por error regionales.
Cree bloqueos de recursos en grupos de recursos.
Implemente una estrategia de equilibrio de carga para las aplicaciones y así obtener una conmutación por error rápida.