4 Soluciones para la replicación sincrónica activa-activa de MySQL

MySQL es un sistema de gestión de bases de datos relacionales de código abierto que se utiliza ampliamente para administrar y almacenar datos estructurados. Es conocido por su simplicidad, facilidad de uso y escalabilidad, lo que lo convierte en una opción popular para diversas aplicaciones que van desde sitios web pequeños hasta grandes empresas.

Para la sincronización de datos en tiempo real, el requisito principal es implementarla basada en registros, lo que permite la sincronización de datos casi en tiempo real. Esto no impone ninguna restricción adicional en el diseño e implementación de la base de datos en sí. El propósito de la replicación activa-activa de MySQL sincrónica es garantizar la disponibilidad continua y la tolerancia a fallas. Aquí hay 4 métodos para lograr la replicación activa-activa sincrónica de MySQL.

Replicación master-master basada en la función nativa de replicación de la base de datos MySQL

Es típicamente adecuada para implementaciones de pequeña a mediana escala.

En esta arquitectura, dos nodos pueden adoptar un modo de doble maestro simple y utilizar una conexión dedicada. En caso de fallo en el nodo master_A, las conexiones de la aplicación pueden cambiar rápidamente al nodo master_B, y viceversa.

Para evitar escenarios de cerebro dividido, donde ambos nodos escriban datos conflictivos, es importante establecer valores diferentes para auto-increment-increment y auto-increment-offset en los dos nodos. Esto se debe a que si el nodo maestro falla inesperadamente o se vuelve no disponible, es posible que algunos eventos de binlog no se repliquen al nodo esclavo. En tales casos, pueden surgir conflictos entre el valor auto-increment generado en el esclavo y el valor original en el maestro.

Sin embargo, si existe un mecanismo de tolerancia a fallos adecuado para resolver conflictos de ID de incremento automático entre maestro y esclavo, es posible evitar el uso de dicho método. En las versiones actualizadas 5.7+ de MySQL, aprovechar la replicación multinuclear puede reducir significativamente la latencia de replicación. Además, otra solución alternativa que es particularmente sensible a la latencia de replicación es la replicación semisincrónica, que ofrece prácticamente ninguna demora. Sin embargo, esto puede resultar en una disminución del rendimiento de concurrencia de transacciones, especialmente en escritura bidireccional. Se requiere una evaluación integral para tomar una decisión.

Solución basada en la replicación de Galera

Galera es un mecanismo de replicación de sincronización de datos multi-maestro proporcionado por Codership. Permite la replicación síncrona de datos y operaciones de lectura y escritura entre múltiples nodos, garantizando alta disponibilidad y consistencia de datos en la base de datos. Las principales soluciones de alta disponibilidad basadas en Galera son MariaDB Galera Cluster y Percona XtraDB Cluster (PXC).

Actualmente, PXC se utiliza más comúnmente y proporciona una consistencia de datos estricta, lo que lo hace particularmente adecuado para el comercio electrónico. Sin embargo, PXC también tiene sus limitaciones. En escenarios con volúmenes altos de transacciones concurrentes, se recomienda utilizar una red InfiniBand para reducir la latencia de la red. Esto es porque PXC puede sufrir de amplificación de escritura y el efecto cuello de botella, lo que resulta en una pérdida significativa de eficiencia concurrente. Al igual que la replicación semisincrónica, la replicación Galera generalmente está limitada a tres nodos. Además, las fluctuaciones de la red pueden causar problemas de rendimiento y estabilidad.

Solución basada en la Replicación de Grupo

MGR (MySQL Group Replication) es una solución de alta disponibilidad oficialmente presentada por MySQL. Proporciona fuertes garantías de consistencia de datos entre los nodos en un clúster de bases de datos a través del protocolo Paxos. MGR se basa en la tecnología de replicación nativa y se ofrece como un plugin. Permite que todos los nodos en el clúster sean escribibles, abordando las limitaciones de rendimiento de un solo clúster, resolviendo el problema de divisiones cerebrales causadas por particiones de red y mejorando la fiabilidad de los datos replicados.

Sin embargo, la realidad es algo dura. Actualmente, no hay muchos adoptantes tempranos de MGR. Además, solo admite tablas InnoDB y requiere que cada tabla tenga una clave primaria para la detección de conflictos del conjunto de escritura. La función GTID debe estar habilitada y el formato del registro binario debe estar configurado en ROW para la elección del líder y el conjunto de escritura. 

COMMIT puede fallar de manera similar a los escenarios de error en el nivel de aislamiento de instantáneas. Actualmente, un clúster MGR (MySQL Group Replication) admite un máximo de 9 nodos. No admite claves foráneas y características de puntos de salvaguarda, lo que impide las verificaciones globales de restricciones y los rollback parciales. El registro binario no admite el checksum de eventos del binlog.

Solución basada en Canal

Para la sincronización en tiempo real de bases de datos, Alibaba tiene un proyecto de código abierto llamado Otter, que permite la replicación síncrona de bases de datos distribuidas. La idea central de Otter sigue basándose en capturar los registros de datos incrementales de las bases de datos para lograr una replicación casi en tiempo real. Otter en sí mismo depende de otro proyecto de código abierto llamado Canal, que se centra en capturar la información de los registros de sincronización incremental de bases de datos.

Actualmente, Otter se centra en lograr la replicación síncrona entre bases de datos MySQL. Utiliza tecnologías similares para lograr la replicación síncrona bidireccional entre dos bases de datos MySQL. Es importante tener en cuenta que la bidireccionalidad aquí significa que los datos pueden sincronizarse de A a B o de B a A, pero puede ser unidireccional en un punto específico en el tiempo.

El proceso de replicación maestro-esclavo se puede dividir en tres pasos:

1. El maestro registra los cambios en el registro binario, que se conocen como eventos del registro binario. Estos eventos pueden ser vistos utilizando el comando "show binlog events".

2. El esclavo copia los eventos del registro binario del maestro en su propio registro de relevo.

3. El esclavo volverá a ejecutar secuencialmente los eventos registrados en el registro de retransmisión para aplicar los cambios del maestro a sus propios datos.

En cuanto al principio del Canal, es bastante sencillo:

1. Canal simula el protocolo de interacción de un esclavo MySQL haciéndose pasar por un esclavo MySQL y enviando una solicitud de volcado al maestro MySQL.

2. Al recibir la solicitud de volcado, el servidor maestro MySQL comienza a enviar los registros binarios al esclavo (que es Canal).

3. Canal luego analiza los objetos del registro binario (originalmente en formato de flujo de bytes) para extraer la información relevante.

Copia de seguridad de bases de datos MySQL con Vinchin Backup & Recovery

Para proteger mejor los datos, se recomienda hacer una copia de seguridad de sus bases de datos. Vinchin Backup & Recovery ofrece una funcionalidad potente para proteger sus bases de datos tanto en máquinas virtuales como en servidores físicos. Al colaborar bien con las copias de seguridad a nivel de VM, se brinda un doble seguro a los usuarios de entornos virtuales para sus datos y sistemas de información clave.

Vinchin Backup & Recovery admite la protección de Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro y MariaDB instalados tanto en máquinas físicas como virtuales con potentes funciones de respaldo y restauración de bases de datos. También proporciona estrategias de respaldo completo, diferencial, incremental y de registro de transacciones para que pueda configurar su propio plan de respaldo según sus necesidades.

Vinchin Backup & Recovery admite copias de seguridad en caliente eficientes sin afectar la operación normal de las bases de datos y es fácil crear un trabajo de copia de seguridad de base de datos personalizado.

1 Seleccione la base de datos objetivo

2 Seleccione el almacenamiento de copia de seguridad

3 Seleccione las estrategias de copia de seguridad

4 Enviar el trabajo

Puedes comenzar a usar este sistema potente con una prueba gratuita completa de 60 días. Solo haz clic en el botón para obtener el paquete de instalación. Puedes hacer clic aquí para obtener más información sobre cómo respaldar MySQL con Vinchin Backup & Recovery.

Conclusión

La replicación sincrónica activa-activa de MySQL está diseñada para proporcionar alta disponibilidad y flexibilidad. Permite que varias instancias de MySQL estén activas simultáneamente y sincronicen datos entre sí, habilitando operaciones de lectura y escritura bidireccionales. Garantiza la disponibilidad continua, el equilibrio de carga, la coherencia de datos y la flexibilidad. Sin embargo, una configuración y gestión adecuadas son cruciales, y la elección de soluciones y herramientas de implementación depende de los requisitos específicos.

Para proteger eficientemente los datos de la base de datos, puede elegir Vinchin Backup & Recovery para realizar copias de seguridad y recuperar la base de datos. No se pierda la prueba gratuita.