Overview of the MGR mode - ApsaraDB RDS: Central de Documentação do Alibaba Cloud

A replicação de grupo do MySQL (MGR) é um modo de replicação distribuída baseado no mecanismo de binary log do MySQL e implementado com o protocolo Paxos. Instâncias do ApsaraDB RDS for MySQL que executam a RDS Cluster Edition oferecem suporte ao MGR.

A replicação tradicional opera de forma assíncrona ou semissíncrona: o nó primário grava uma transação em seu binary log e a propaga para os nós secundários, sem garantia de recebimento dos dados antes de uma falha. O MGR adota uma abordagem diferente: antes da confirmação de uma transação, a maioria dos nós deve acusar o recebimento dos respectivos binary logs. Esse modelo de confirmação pela maioria oferece garantias de dados mais robustas que os modos de replicação tradicionais.

Recurso	MGR	Replicação semissíncrona	Replicação assíncrona
Confiabilidade dos dados	★★★★★	★★★	★
Consistência dos dados	Garantida	Não garantida	Não garantida
Consistência global de transações	Suportada	Não suportada	Não suportada

Vantagens

Alta confiabilidade dos dados

O MGR utiliza a regra da maioria do protocolo Paxos: uma transação só é confirmada após a maioria dos nós no cluster RDS receber seus binary logs. Isso evita perda de dados mesmo quando uma minoria de nós apresenta falhas.

Por exemplo, em um cluster de 5 nós onde 3 recebem os binary logs e 2 não:

Se os 2 nós com falha estiverem entre os que receberam os binary logs, pelo menos 1 nó com os dados permanecerá em execução.
Caso os 2 nós com falha estejam entre os que não receberam os binary logs, todos os 3 nós com os dados permanecerão operacionais.

Forte consistência dos dados

Na replicação tradicional primário-secundário, ocorre inconsistência se o nó primário falhar após gravar uma transação em seu binary log, mas antes de transmiti-la aos nós secundários. O MGR impede essa situação: as transações são transmitidas para outros nós antes da gravação no binary log. Assim, cada transação confirmada já existe na maioria dos nós.

Quando o nó primário falha e reinicia, ele reingressa automaticamente no cluster e sincroniza quaisquer binary logs ausentes para se atualizar.

Consistência global de transações

Defina o parâmetro group_replication_consistency para controlar o nível de consistência das operações de leitura e escrita:

Forte consistência de leitura (group_replication_consistency=BEFORE nos nós secundários): uma consulta executa somente após a conclusão de todas as transações anteriores no nó primário. Essa configuração garante que as leituras nos nós secundários nunca retornem dados desatualizados.
Forte consistência de escrita (group_replication_consistency=AFTER no nó primário): uma transação de escrita confirma apenas após aplicação bem-sucedida em todos os nós.

Métodos de implantação

O MGR oferece suporte a dois modos de implantação. A tabela abaixo compara capacidades e compensações para ajudar na escolha do modo adequado à sua carga de trabalho.

	Líder múltiplo	Líder único
Nós de escrita	Todos os nós	Apenas o nó primário
Nós de leitura	Todos os nós	Todos os nós não primários
Throughput de escrita	Maior (escritas paralelas entre nós)	Menor (caminho único de escrita)
Throughput de leitura	Padrão	Maior (nós somente leitura otimizados)
Disponibilidade quando uma minoria de nós falha	Degradada — nós posteriores ao nó com falha na ordem de polling não conseguem enviar dados	Não afetada — o cluster continua operando desde que a maioria dos nós esteja disponível
Failover primário/secundário em caso de falha do primário	N/A	Automático, baseado no protocolo Paxos
Garantia de consistência de dados	Forte	Forte

Líder múltiplo

Todos os nós processam solicitações de leitura e escrita. O modo de líder múltiplo aumenta o throughput de escrita ao utilizar mecanismos Paxos para gravar vários registros simultaneamente e detectar conflitos no nível de linha, assegurando que todos os nós recebam os dados na mesma ordem.

Limitação: Quando um nó sofre instabilidade ou falha, os nós listados após ele na ordem de polling não conseguem enviar dados, tornando o cluster temporariamente indisponível. Trata-se de uma limitação inerente ao modo de líder múltiplo impossível de eliminar.

Líder único

Apenas um nó processa solicitações de escrita; todos os demais processam solicitações de leitura. O modo de líder único emprega a estratégia de replicação de líder único do protocolo Paxos para maximizar o throughput de leitura e manter a alta disponibilidade:

Se um nó secundário falhar e a maioria dos nós permanecer disponível, o cluster continua operando sem interrupções.
Em caso de falha do nó primário, o cluster executa automaticamente um failover primário/secundário com base no protocolo Paxos para preservar a forte consistência dos dados.

O ApsaraDB RDS for MySQL permite criar clusters RDS que utilizam MGR no modo de líder único. Nessa configuração, os nós somente leitura são otimizados para melhorar o desempenho do cluster, garantindo simultaneamente alta confiabilidade e forte consistência dos dados.

Arquitetura

O MGR adiciona três camadas abaixo das camadas de servidor e de réplica do MySQL:

Camada	Função
Camada de lógica de replicação de grupo	Interage com a camada de servidor do MySQL para enviar e receber transações da camada do sistema de comunicação de grupo (GCS) e aplicar transações
Camada GCS	Entrega mensagens, detecta falhas e gerencia a associação ao cluster
Camada XCom	Garante a consistência da ordem dos dados e a disponibilidade da maioria dos nós, com base no protocolo Paxos

Protocolo Paxos

O protocolo Paxos desempenha duas funções no MGR:

Garante que todos os nós do cluster recebam os binary logs de uma transação na mesma ordem — aspecto essencial para o modo de líder múltiplo.
Assegura que uma transação confirme apenas após a maioria dos nós acusar o recebimento de seus binary logs.

A camada XCom baseia-se no protocolo Mencius, uma variante do Paxos que substitui o ordenamento baseado em bloqueios por um mecanismo de polling. Essa abordagem proporciona balanceamento de carga entre os nós e melhora a eficiência geral.

Funcionamento do modo de líder múltiplo

No modo de líder múltiplo, cada nó pertence a um grupo Paxos. A camada XCom impõe uma ordem global consistente de dados por meio de dois mecanismos:

Envio serial dentro de um grupo: Os dados de cada grupo são enviados serialmente para garantir a consistência da ordem interna do grupo.
Polling entre grupos: Quando vários grupos enviam dados, um mecanismo de polling impõe uma ordem consistente globalmente. Por exemplo, os dados são enviados na sequência (1,1), (1,2), (1,3).

Na notação (m,n), n representa o número do grupo e m é o número de sequência do registro de dados enviado por esse grupo. Por exemplo, (2,1) indica que o Grupo 1 está enviando seu segundo registro de dados.

O mecanismo noop gerencia nós ociosos: se um nó não tiver dados para enviar, mas dados de nós listados após ele já tiverem sido recebidos pela maioria do cluster, esse nó transmite um estado noop para pular a si mesmo e desbloquear o próximo nó na ordem de polling.

Funcionamento do modo de líder único

Como apenas um nó envia transações de escrita no modo de líder único, somente um grupo Paxos precisa estar ativo. O receptor ignora todos os outros grupos Paxos durante o polling. Isso elimina o problema de disponibilidade relacionado a noop presente no modo de líder múltiplo: desde que a maioria dos nós esteja disponível, o cluster permanece operacional mesmo diante de falhas individuais.

Os nós secundários no modo de líder único não enviam transações — transmitem apenas informações de gerenciamento do cluster. Antes de enviar qualquer dado, um nó secundário deve solicitar um slot de envio ao nó primário. A notação <3,1> no diagrama acima representa esse slot. Como as mensagens de gerenciamento do cluster são pouco frequentes, a sobrecarga de latência desse mecanismo de solicitação de slot não causa impacto significativo no throughput do cluster.

Camada de lógica de replicação de grupo

A camada de lógica de replicação de grupo cuida da propagação de transações e da detecção de conflitos tanto nos nós primários quanto nos secundários.

Fluxo do nó primário:

Antes da confirmação de uma transação, a camada de lógica de replicação de grupo envia seus binary logs para a camada XCom, que os transmite para todos os outros nós. Após a maioria dos nós confirmar o recebimento, a detecção de conflitos executa:

Sucesso: a transação é gravada no arquivo de binary log e confirmada.
Falha: a transação é revertida.

Fluxo do nó secundário:

Depois que a maioria dos nós confirma uma transação, a camada XCom a encaminha para a camada de lógica de replicação de grupo para detecção de conflitos:

Sucesso: a transação é gravada no arquivo de relay log e aplicada pela thread applier.
Falha: os dados da transação são descartados.

Detecção de conflitos

Quando a detecção de conflitos é necessária:

Modo de líder múltiplo: Obrigatória para cada operação de escrita, pois vários nós podem aceitar escritas simultaneamente.
Modo de líder único: Necessária apenas quando ocorre um failover primário/secundário e transações de escrita chegam ao novo primário antes da aplicação total dos relay logs do primário original.

Funcionamento:

Cada nó mantém um array hash de informações de autenticação de transações:

Chave: O valor hash de uma linha de dados modificada (com base em sua chave primária).
Valor: A união do identificador global de transação (GTID) da transação atual e gtid_executed — o conjunto de todos os GTIDs confirmados no nó source antes da confirmação da transação atual.

Antes da confirmação de uma transação, cada nó cria um conjunto de dependências consultando os valores hash de todas as linhas modificadas pela transação em seu array de autenticação. O conjunto de dependências representa todas as transações que devem ter sido concluídas antes que a transação atual possa confirmar com segurança.

O sistema então compara o conjunto de confirmação da transação (transações confirmadas antes desta no nó source) com o conjunto de dependências:

Se o conjunto de confirmação contiver o conjunto de dependências, a transação passa na detecção de conflitos, confirma no nó source e grava nos relay logs dos outros nós.
Caso o conjunto de confirmação não contenha o conjunto de dependências, a transação falha na detecção de conflitos, reverte no nó source e tem seus dados de relay log descartados nos demais nós.

Exclusão de dados de autenticação obsoletos:

Assim que uma transação é aplicada em todos os nós do cluster, suas linhas podem ser removidas do array de autenticação. O MGR limpa os dados de autenticação obsoletos a cada 60 segundos.

Otimizações do AliSQL para estabilidade do MGR

O modo de líder único melhora significativamente a estabilidade do MGR, mas um cenário específico ainda apresenta problemas: quando um nó secundário sofre alta latência, ele não consegue aplicar transações com rapidez suficiente, causando acúmulo de informações de autenticação. Isso gera dois problemas:

Alto consumo de memória, com risco de erros de falta de memória (OOM).
Sobrecarga elevada devido à limpeza periódica dos dados de autenticação acumulados, o que degrada o desempenho do cluster.

O AliSQL resolve essa questão reduzindo o volume de informações de autenticação mantido em cada nó:

Nó primário: O array de autenticação no nó primário nunca é usado para detecção de conflitos no modo de líder único. O AliSQL o remove completamente, eliminando o consumo de memória e a sobrecarga de limpeza associados.
Nó secundário: As informações de autenticação são necessárias apenas quando group_replication_consistency está definido como EVENTUAL. A configuração EVENTUAL permite que um primário recém-eleito atenda ao tráfego externo imediatamente, sem aguardar a conclusão da reprodução do relay log — o que pode causar conflitos de dados e raramente é usado em produção. Quando EVENTUAL não é utilizado, o AliSQL também remove o array de autenticação dos nós secundários, reduzindo substancialmente o consumo de memória e melhorando a estabilidade do cluster.