MySQL tiene una larga tradición en la replicación geográfica. La distribución de clústeres a centros de datos remotos reduce los efectos de la latencia geográfica al acercar los datos al usuario. También proporciona una capacidad de recuperación ante desastres. Debido al costo significativo de duplicar el hardware en un sitio separado, no muchas empresas podían pagarlo en el pasado. Otro costo es el personal calificado que puede diseñar, implementar y mantener un entorno sofisticado de múltiples centros de datos.
Con la revolución de la automatización de la nube y DevOps, tener un centro de datos distribuido nunca ha sido más accesible para las masas. Los proveedores de la nube están aumentando la gama de servicios que ofrecen a un mejor precio. Se pueden crear entornos híbridos entre nubes con datos repartidos por todo el mundo. Se pueden hacer planes de DR flexibles y escalables para abordar una amplia gama de escenarios de disrupción. En algunos casos, eso puede ser solo una copia de seguridad almacenada fuera del sitio. En otros casos, puede ser una copia 1 a 1 de un entorno de producción que se ejecuta en otro lugar.
En este blog, analizaremos algunos de estos casos y abordaremos escenarios comunes.
Almacenamiento de copias de seguridad en la nube
Un plan de DR es un término general que describe un proceso para recuperar sistemas de TI interrumpidos y otros activos críticos que utiliza una organización. La copia de seguridad es el método principal para lograr esto. Cuando una copia de seguridad está en el mismo centro de datos que sus servidores de producción, corre el riesgo de que se eliminen todos los datos en caso de que pierda ese centro de datos. Para evitar eso, debe tener la política de crear una copia en otra ubicación física. Todavía es una buena práctica mantener una copia de seguridad en el disco para reducir el tiempo necesario para la restauración. En la mayoría de los casos, mantendrá su copia de seguridad principal en el mismo centro de datos (para minimizar el tiempo de restauración), pero también debe tener una copia de seguridad que pueda usarse para restaurar los procedimientos comerciales cuando el centro de datos principal está inactivo.
ClusterControl:Subir copia de seguridad a la nube ClusterControl permite una integración perfecta entre su entorno de base de datos y la nube. Proporciona opciones para migrar datos a la nube. Ofrecemos una combinación completa de copias de seguridad de bases de datos para Amazon Web Services (AWS), Google Cloud Services o Microsoft Azure. Las copias de seguridad ahora se pueden ejecutar, programar, descargar y restaurar directamente desde el proveedor de la nube de su elección. Esta capacidad proporciona mayor redundancia, mejores opciones de recuperación ante desastres y beneficios tanto en rendimiento como en ahorro de costos.
ClusterControl:administración de credenciales de nube El primer paso para configurar la "copia de seguridad a prueba de fallos del centro de datos" es proporcionar las credenciales de su operador de nube. Puede elegir entre varios proveedores aquí. Echemos un vistazo al proceso configurado para el operador de nube más popular:AWS.
ClusterControl:agregar credenciales de nube Todo lo que necesita es el ID de clave de AWS y el secreto de la región en la que desea almacenar su copia de seguridad. Puede obtener eso desde la consola de AWS. Puedes seguir algunos pasos para conseguirlo.
- Utilice la dirección de correo electrónico y la contraseña de su cuenta de AWS para iniciar sesión en la Consola de administración de AWS como usuario raíz de la cuenta de AWS.
- En la página Panel de IAM, elija el nombre de su cuenta en la barra de navegación y luego seleccione Mis credenciales de seguridad .
- Si ve una advertencia sobre el acceso a las credenciales de seguridad de su cuenta de AWS, elija Continuar con Credenciales de seguridad .
- Expanda la sección Claves de acceso (ID de clave de acceso y clave de acceso secreta).
- Elija Crear nueva clave de acceso . Luego elija Descargar archivo clave para guardar el ID de la clave de acceso y la clave de acceso secreta en un archivo en su computadora. Después de cerrar el cuadro de diálogo, no podrá volver a recuperar esta clave de acceso secreta.
ClusterControl:copia de seguridad en la nube híbrida Cuando todo esté configurado, puede ajustar su programa de copia de seguridad y habilitar la opción de copia de seguridad en la nube. Para reducir el tráfico de red, asegúrese de habilitar la compresión de datos. Hace que las copias de seguridad sean más pequeñas y minimiza el tiempo necesario para la carga. Otra buena práctica es cifrar la copia de seguridad. ClusterControl crea una clave automáticamente y la usa si decide restaurarla. Las políticas de copias de seguridad avanzadas deben tener diferentes tiempos de mantenimiento para las copias de seguridad almacenadas en servidores en el mismo centro de datos y las copias de seguridad almacenadas en otra ubicación física. Debe establecer un período de retención más prolongado para las copias de seguridad basadas en la nube y un período más corto para las copias de seguridad almacenadas cerca del entorno de producción, ya que la probabilidad de restauración disminuye con la vida útil de la copia de seguridad.
ClusterControl:política de retención de copias de seguridad Amplíe su clúster con la replicación asíncrona
Galera con replicación asíncrona puede ser una excelente solución para construir un nodo DR activo en un centro de datos remoto. Hay algunas buenas razones para adjuntar un esclavo asíncrono a un Galera Cluster. Las consultas de tipo OLAP de ejecución prolongada en un nodo de Galera pueden ralentizar todo un clúster. Con la opción de aplicación retrasada, la replicación retrasada puede salvarlo de errores humanos, por lo que todas esas entradas doradas no se aplicarán inmediatamente a su nodo de respaldo.
ClusterControl:replicación retrasada En ClusterControl, la ampliación de un grupo de nodos de Galera con replicación asíncrona se realiza en un asistente de una sola página. Debe proporcionar la información necesaria sobre su servidor esclavo futuro o existente. El esclavo se configurará a partir de una copia de seguridad existente o de un XtraBackup recién transmitido del maestro al esclavo.
Equilibradores de carga en varios centros de datos
Los balanceadores de carga son un componente crucial en la alta disponibilidad de la base de datos MySQL y MariaDB. No basta con tener un clúster que abarque varios centros de datos. Todavía necesita sus servicios para acceder a ellos. Una falla de un balanceador de carga que está disponible en un centro de datos hará que todo su entorno sea inalcanzable.
Proxies web en entorno de clúster Uno de los métodos populares para ocultar la complejidad de la capa de base de datos de una aplicación es usar un proxy. Los proxies actúan como un punto de entrada a las bases de datos, rastrean el estado de los nodos de la base de datos y siempre deben dirigir el tráfico solo a los nodos que están disponibles. ClusterControl facilita la implementación y configuración de varias tecnologías de balanceo de carga diferentes para MySQL y MariaDB, incluidas ProxySQL, HAProxy, con una interfaz gráfica de apuntar y hacer clic.
ClusterControl:equilibrador de carga HA También permite hacer que este componente sea redundante agregando keepalive encima. Para evitar que sus balanceadores de carga sean un único punto de falla, uno configuraría dos instancias HAProxy, ProxySQL o MariaDB Maxscale idénticas (una activa y otra en un DC diferente como en espera) y usaría Keepalived para ejecutar el Protocolo de redundancia de enrutador virtual (VRRP) entre a ellos. VRRP proporciona una dirección IP virtual al balanceador de carga activo y transfiere la IP virtual al HAProxy en espera en caso de falla. Es transparente porque las dos instancias de proxy no necesitan un estado compartido.
Por supuesto, hay muchas cosas a considerar para hacer que sus bases de datos sean inmunes a las fallas del centro de datos.
¡La planificación y la automatización adecuadas harán que funcione! ¡Feliz agrupamiento!
