Descripción general del modo MGR - ApsaraDB RDS - Centro de documentación de Alibaba Cloud

La replicación de grupo de MySQL (MGR) es un modo de replicación distribuida basado en el mecanismo de registro binario de MySQL e implementado mediante el protocolo Paxos. Las instancias de ApsaraDB RDS for MySQL que ejecutan RDS Cluster Edition son compatibles con MGR.

La replicación tradicional es asíncrona o semisíncrona: el nodo principal escribe una transacción en su registro binario y luego la propaga a los nodos secundarios, sin garantía de que estos hayan recibido los datos antes de que ocurra un fallo. MGR adopta un enfoque fundamentalmente distinto: antes de confirmar una transacción, la mayoría de los nodos debe confirmar la recepción de sus registros binarios. Este modelo de confirmación por mayoría otorga a MGR garantías de datos más sólidas que los modos de replicación tradicionales.

Función	MGR	Replicación semisíncrona	Replicación asíncrona
Fiabilidad de los datos	★★★★★	★★★	★
Consistencia de los datos	Garantizada	No garantizada	No garantizada
Consistencia global de transacciones	Compatible	No compatible	No compatible

Ventajas

Alta fiabilidad de los datos

MGR utiliza la regla de mayoría del protocolo Paxos: una transacción se confirma solo después de que la mayoría de los nodos del clúster de RDS haya recibido sus registros binarios. Esto evita la pérdida de datos incluso cuando falla una minoría de nodos.

Por ejemplo, en un clúster de 5 nodos donde 3 reciben los registros binarios y 2 no:

Si los 2 nodos con fallos se encuentran entre los que recibieron los registros binarios, como mínimo 1 nodo con los datos sigue en ejecución.
Si los 2 nodos con fallos se encuentran entre los que no recibieron los registros binarios, los 3 nodos con los datos siguen en ejecución.

Sólida consistencia de los datos

En la replicación tradicional principal-secundario, si el nodo principal falla después de escribir una transacción en su registro binario pero antes de transmitirla a los nodos secundarios, se produce una inconsistencia de datos. MGR evita esto: las transacciones se transmiten a otros nodos antes de escribirse en el registro binario, por lo que cada transacción confirmada ya reside en la mayoría de los nodos.

Si el nodo principal falla y se reinicia, se reincorpora automáticamente al clúster y sincroniza los registros binarios faltantes para ponerse al día.

Consistencia global de transacciones

Establezca el parámetro group_replication_consistency para controlar el nivel de consistencia de las operaciones de lectura y escritura:

Consistencia fuerte de lectura (group_replication_consistency=BEFORE en nodos secundarios): una consulta se ejecuta solo después de completar todas las transacciones anteriores en el nodo principal. Esto garantiza que las lecturas en los nodos secundarios nunca estén desactualizadas.
Consistencia fuerte de escritura (group_replication_consistency=AFTER en el nodo principal): una transacción de escritura se confirma solo después de aplicarse correctamente en todos los nodos.

Métodos de despliegue

imagen

MGR admite dos modos de despliegue. La siguiente tabla compara sus capacidades y compromisos para ayudarle a elegir el modo adecuado para su carga de trabajo.

	Líder múltiple	Líder único
Nodos de escritura	Todos los nodos	Solo el nodo principal
Nodos de lectura	Todos los nodos	Todos los nodos no principales
Throughput de escritura	Mayor (escrituras paralelas en varios nodos)	Menor (ruta de escritura única)
Throughput de lectura	Estándar	Mayor (nodos de solo lectura optimizados)
Disponibilidad cuando falla una minoría de nodos	Degradada: los nodos posteriores al nodo fallido en el orden de sondeo no pueden enviar datos	Sin afectación: el clúster continúa mientras la mayoría de los nodos esté disponible
Conmutación principal/secundario tras fallo del principal	N/A	Automática, basada en el protocolo Paxos
Garantía de consistencia de datos	Fuerte	Fuerte

Líder múltiple

Todos los nodos procesan solicitudes de lectura y escritura. El modo de líder múltiple aumenta el throughput de escritura al usar mecanismos de Paxos para escribir varios registros simultáneamente y detectar conflictos a nivel de fila, de modo que todos los nodos reciban los datos en el mismo orden.

Limitación: Cuando un nodo experimenta inestabilidad o un fallo, los nodos listados después de él en el orden de sondeo no pueden enviar datos, lo que deja el clúster temporalmente no disponible. Esta limitación es inherente al modo de líder múltiple y no se puede eliminar.

Líder único

Solo un nodo procesa las solicitudes de escritura; los demás procesan las de lectura. El modo de líder único utiliza la estrategia de replicación de líder único del protocolo Paxos para maximizar el throughput de lectura y mantener la alta disponibilidad:

Si falla un nodo secundario y la mayoría de los nodos permanece disponible, el clúster continúa operando sin interrupciones.
Si falla el nodo principal, el clúster realiza automáticamente una conmutación principal/secundario basada en el protocolo Paxos para mantener una sólida consistencia de los datos.

ApsaraDB RDS for MySQL permite crear clústeres de RDS que usan MGR en modo de líder único. En este modo, los nodos de solo lectura se optimizan para mejorar el rendimiento del clúster y, al mismo tiempo, garantizar alta fiabilidad y sólida consistencia de los datos.

Arquitectura

imagen

MGR añade tres capas debajo de las capas de servidor y réplica de MySQL:

Capa	Rol
Capa de lógica de replicación de grupo	Interactúa con la capa de servidor de MySQL para enviar y recibir transacciones hacia y from la capa del sistema de comunicación grupal (GCS), y aplica las transacciones
Capa GCS	Entrega mensajes, detecta fallos y gestiona la membresía del clúster
Capa XCom	Garantiza la consistencia del orden de los datos y la disponibilidad de la mayoría de los nodos, basándose en el protocolo Paxos

Protocolo Paxos

El protocolo Paxos desempeña dos funciones en MGR:

Garantiza que todos los nodos del clúster reciban los registros binarios de una transacción en el mismo orden, algo esencial para el modo de líder múltiple.
Asegúrese de que una transacción se confirme solo después de que la mayoría de los nodos confirme la recepción de sus registros binarios.

La capa XCom se basa en el protocolo Mencius, una variante basada en Paxos que reemplaza el ordenamiento basado en bloqueos de Paxos con un mecanismo de sondeo. Esto logra un equilibrio de carga entre los nodos y mejora la eficiencia general.

Funcionamiento del modo de líder múltiple

imagen

En el modo de líder múltiple, cada nodo pertenece a un grupo Paxos. La capa XCom impone un orden global consistente de los datos mediante dos mecanismos:

Envío serial dentro de un grupo: Los datos dentro de cada grupo se envían de forma serial para garantizar la consistencia del orden dentro del grupo.
Sondeo entre grupos: Cuando varios grupos envían datos, un mecanismo de sondeo impone un orden consistente a nivel global. Por ejemplo, los datos se envían en el orden (1.1), (1.2), (1.3).

En la notación (m,n), n es el número de grupo y m es el número de secuencia del registro de datos enviado por ese grupo. Por ejemplo, (2.1) significa que el Grupo 1 está enviando su segundo registro de datos.

El mecanismo noop gestiona los nodos inactivos: si un nodo no tiene datos para enviar, pero la mayoría del clúster ya recibió los datos de los nodos listados después de él, el nodo transmite un estado noop para saltarse a sí mismo y desbloquear al siguiente nodo en el orden de sondeo.

Funcionamiento del modo de líder único

imagen

Dado que solo un nodo envía transacciones de escritura en el modo de líder único, solo un grupo Paxos necesita estar activo. El receptor ignora todos los demás grupos Paxos durante el sondeo. Esto elimina el problema de disponibilidad relacionado con noop presente en el modo de líder múltiple: mientras la mayoría de los nodos esté disponible, el clúster permanece operativo incluso si fallan nodos individuales.

imagen

Los nodos secundarios en el modo de líder único no envían transacciones, solo información de gestión del clúster. Antes de enviar cualquier dato, un nodo secundario debe solicitar un espacio de envío al nodo principal. La notación <3,1> en el diagrama anterior representa dicho espacio. Dado que los mensajes de gestión del clúster son poco frecuentes, la sobrecarga de latencia de este mecanismo de solicitud de espacio no afecta significativamente el throughput del clúster.

Capa de lógica de replicación de grupo

imagen

La capa de lógica de replicación de grupo maneja la propagación de transacciones y la detección de conflictos tanto en los nodos principales como en los secundarios.

Flujo del nodo principal:

Antes de confirmar una transacción, la capa de lógica de replicación de grupo envía sus registros binarios a la capa XCom, que los transmite a todos los demás nodos. Después de que la mayoría de los nodos confirma la recepción, se ejecuta la detección de conflictos:

Aprobada: la transacción se escribe en el archivo de registro binario y se confirma.
Fallida: la transacción se revierte.

Flujo del nodo secundario:

Después de que la mayoría de los nodos confirma una transacción, la capa XCom la reenvía a la capa de lógica de replicación de grupo para la detección de conflictos:

Aprobada: la transacción se escribe en el archivo de registro de retransmisión y la aplica el hilo de aplicación.
Fallida: los datos de la transacción se descartan.

Detección de conflictos

Cuándo se requiere la detección de conflictos:

Modo de líder múltiple: Obligatoria para cada operación de escritura, porque varios nodos pueden aceptar escrituras simultáneamente.
Modo de líder único: Obligatoria solo cuando ocurre una conmutación principal/secundario y llegan transacciones de escritura al nuevo nodo principal antes de aplicar completamente sus registros de retransmisión del nodo principal original.

Cómo funciona:

Cada nodo mantiene un arreglo de hash con información de autenticación de transacciones:

Clave: El valor de hash de una fila de datos modificada (basado en su clave principal).
Valor: La unión del identificador global de transacción (GTID) de la transacción actual y gtid_executed (el conjunto de todos los GTID confirmados en el nodo origen antes de confirmar la transacción actual).

Antes de confirmar una transacción, cada nodo construye un conjunto de dependencias al buscar los valores de hash de todas las filas modificadas por la transacción en su arreglo de autenticación. El conjunto de dependencias representa todas las transacciones que deben haberse completado antes de que la transacción actual pueda confirmarse de manera segura.

Luego, el sistema compara el conjunto de confirmación de la transacción (transacciones confirmadas antes de esta en el nodo origen) con el conjunto de dependencias:

Si el conjunto de confirmación contiene el conjunto de dependencias, la transacción supera la detección de conflictos, se confirma en el nodo origen y se escribe en los registros de retransmisión de los demás nodos.
Si el conjunto de confirmación no contiene el conjunto de dependencias, la transacción falla la detección de conflictos, se revierte en el nodo origen y sus datos de registro de retransmisión se descartan en los demás nodos.

Eliminación de datos de autenticación obsoletos:

Una vez aplicada una transacción en todos los nodos del clúster, sus filas pueden eliminarse del arreglo de autenticación. MGR purga los datos de autenticación obsoletos cada 60 segundos.

Optimizaciones de AliSQL para la estabilidad de MGR

El modo de líder único mejora significativamente la estabilidad de MGR, pero un escenario específico sigue siendo problemático: cuando un nodo secundario experimenta alta latencia, no puede aplicar transacciones con la suficiente rapidez, lo que provoca la acumulación de información de autenticación. Esto genera dos problemas:

Alto consumo de memoria, con riesgo de errores de falta de memoria (OOM).
Alta sobrecarga por la purga periódica de los datos de autenticación acumulados, lo que degrada el rendimiento del clúster.

AliSQL soluciona esto al reducir el volumen de información de autenticación mantenida en cada nodo:

Nodo principal: El arreglo de autenticación en el nodo principal nunca se usa para la detección de conflictos en el modo de líder único. AliSQL lo elimina por completo, suprimiendo así su consumo de memoria y la sobrecarga de purga.
Nodo secundario: La información de autenticación solo es necesaria cuando group_replication_consistency se establece en EVENTUAL. La configuración EVENTUAL permite que un nodo principal recién elegido atienda tráfico externo de inmediato sin esperar a que finalice la reproducción del registro de retransmisión, lo cual puede causar conflictos de datos y rara vez se usa en producción. Cuando no se usa EVENTUAL, AliSQL también elimina el arreglo de autenticación de los nodos secundarios, lo que reduce sustancialmente el consumo de memoria y mejora la estabilidad del clúster.