PolarDB:Physical replication-based semi-sync in PolarDB for MySQL

Contexto

O MySQL padrão oferece replicação semissíncrona baseada no log binário. Nesse modo, o nó primário precisa aguardar a confirmação de um nó secundário sobre o recebimento do log binário gerado por uma transação antes de efetuar o commit. Esse método de sincronização introduz latência adicional e afeta o desempenho de escrita do primário.

O PolarDB for MySQL adota uma arquitetura de replicação física para sincronizar eficientemente o redo log entre as zonas primária e secundária. Essa abordagem melhora significativamente a eficiência da replicação semissíncrona e reduz a perda de desempenho no nó primário. Em cargas de trabalho de alta concorrência, a degradação de desempenho é de aproximadamente 10% em comparação à replicação assíncrona.

Comparada à replicação semissíncrona baseada em log binário do MySQL padrão, a abordagem de replicação física do PolarDB for MySQL proporciona maior eficiência de sincronização. Durante a execução da transação, os registros de redo log são gerados e transmitidos para a zona secundária em tempo real. Assim, no momento do commit, o primário só precisa aguardar a sincronização bem-sucedida do registro de redo log correspondente na zona secundária. Por outro lado, o mecanismo semissíncrono tradicional baseado em log binário gera o log completo apenas no momento do commit. O primário só retorna uma mensagem de sucesso ao cliente após a sincronização integral desse log.

Funcionamento

A replicação semissíncrona do PolarDB for MySQL usa uma arquitetura de replicação física para sincronizar dados entre as zonas primária e secundária por meio de redo logs. Para solicitações de escrita, os registros de redo log são gerados quando os dados são modificados na zona primária e, em seguida, sincronizados pelo link de replicação física. O primário deve aguardar o reconhecimento de recebimento do redo log pela zona secundária antes que a transação de escrita correspondente retorne uma resposta de sucesso.

• Tempo máximo de espera antes do commit

  Para evitar que problemas na zona secundária bloqueiem indefinidamente as solicitações de escrita na zona primária, o kernel limita o tempo máximo de espera antes do commit de uma transação de escrita. Caso a zona secundária não envie um reconhecimento dentro desse período, o primário efetua o commit da transação automaticamente.

• Mecanismo adaptativo

  Em casos extremos, a zona secundária pode falhar ao enviar reconhecimentos tempestivos para a zona primária. Isso faz com que cada solicitação de escrita aguarde até atingir o tempo limite antes do commit, resultando em perda de desempenho. Para prevenir esse problema, a semi-sync inclui um mecanismo adaptativo que monitora dinamicamente a comunicação de rede entre as zonas primária e secundária. Se ocorrerem timeouts frequentes, o sistema reverte automaticamente para replicação assíncrona, garantindo que as escritas na zona primária não sejam afetadas. Quando o sistema detecta que a sincronização voltou ao normal, ele reativa a semi-sync automaticamente.

Aplicabilidade

Seu cluster deve atender aos seguintes requisitos:

• **Edição do produto**: Enterprise Edition e Standard Edition

• **Versão do mecanismo**:

  • MySQL 8.0.1:

    • Versão de revisão 8.0.1.35.1 ou posterior: permite ative a semi-sync.

    • Versão de revisão 8.0.1.1.40 ou posterior: permite ative a semi-sync e oferece suporte ao mecanismo adaptativo.

    • Versão de revisão 8.0.1.1.44.2 ou posterior: permite ative a semi-sync e disponibiliza o parâmetro innodb_polar_wait_slave_reply_max_time para controlar o tempo máximo de espera padrão antes do commit de uma transação de escrita. O valor padrão é 500 ms.

  • MySQL 8.0.2: Versão de revisão 8.0.2.2.32 e posterior: permite ative a semi-sync, com suporte também ao mecanismo adaptativo e ao parâmetro innodb_polar_wait_slave_reply_max_time.

Precauções

RPO e RTO:

• Na replicação assíncrona, um failover automático entre zonas envolve perda de dados. O RPO é inferior a 100 ms na maioria dos casos e menor que 60 s no pior cenário. Avalie o impacto antes de utilizar este recurso.

• Ative a replicação semissíncrona reduz o desempenho em cerca de 10%. O tempo de espera padrão para o commit da transação é de 500 ms. Se esse tempo for excedido, o sistema reverte para replicação assíncrona e deixa de aguardar a sincronização com a zona secundária. Quando não ocorre reversão, o RPO é 0.

• O RTO é inferior a 30 s tanto para replicação assíncrona quanto para semissíncrona.

Testes de desempenho

Método de teste: este teste compara o desempenho em consultas por segundo (QPS) de clusters com especificações idênticas em três modos: PolarDB for MySQL com replicação assíncrona, PolarDB for MySQL com semi-sync e MySQL padrão com semi-sync.

Ferramenta de teste: Sysbench (oltp_write_only).

Especificações do teste: 16 núcleos, 64 GB.

Versão testada: PolarDB for MySQL 8.0.1 com versão de revisão 8.0.1.35.1. O desempenho pode variar ligeiramente em relação à versão mais recente.

Volume de dados: 10 tabelas, com 10 milhões de linhas por tabela.

Os resultados indicam que, em cenários de alta concorrência, ative a replicação semissíncrona reduz o desempenho em aproximadamente 10%. Independentemente do nível de concorrência, o desempenho da replicação semissíncrona baseada em redo log no PolarDB for MySQL supera o da replicação semissíncrona baseada em log binário no MySQL.

Perguntas frequentes

P1: Por que o desempenho degrada mais de 10% após eu ative a semi-sync?

R1: Em cenários de alta concorrência, a melhor estimativa de degradação de desempenho é de aproximadamente 10%. Isso ocorre porque os redo logs são processados em lotes, o que reduz eficazmente a sobrecarga causada pela latência de rede. Em cenários de baixa concorrência, o ganho de desempenho proveniente do processamento em lotes é menos significativo, podendo levar a uma degradação mais acentuada. Com uma única thread de escrita, a E/S de redo não pode ser agrupada em lotes, e o atraso adicional de ida e volta na rede, decorrente da ativação da replicação semissíncrona, reduz significativamente o desempenho.

P2: Por que não consigo ver o parâmetro innodb_polar_wait_slave_reply_max_time no console? Como ajustá-lo para um valor adequado?

R2: A modifique desse parâmetro é possível apenas em clusters PolarDB for MySQL Enterprise Edition com versão principal 8.0.1 e versão de revisão 8.0.1.1.44.2 ou superior. Caso não encontre o parâmetro no console, verifique primeiro se a versão do seu cluster atende aos requisitos. Se não atender, realize uma atualização de versão.

Na maioria dos casos, não é necessário modifique esse parâmetro. O valor padrão é 500 ms. Se você tiver requisitos específicos, como garantir que uma transação aguarde a sincronização com a zona secundária antes do commit, aumente esse valor. No entanto, o padrão de 500 ms é suficiente para a maioria dos cenários. Para limitar o tempo de espera da transação, diminua o valor do parâmetro. Observe que definir um valor muito pequeno, como 0 ou 1 ms, pode fazer com que o modo semi-sync reverta para replicação assíncrona. Isso acontece porque a latência de rede entre zonas de disponibilidade geralmente fica dentro de 1 ms, e a replicação semissíncrona exige pelo menos uma ida e volta na rede. Portanto, considere a latência de rede do seu ambiente ao modifique esse parâmetro.

P3: Quando o mecanismo adaptativo da semi-sync entra em vigor? Posso ative a semi-sync mas desativar o mecanismo adaptativo?

R3: Atualmente, ao ative a semi-sync, o mecanismo adaptativo também é habilitado por padrão. Ele monitora dinamicamente o status de sincronização entre as zonas primária e secundária e faz ajustes em tempo real. Não é possível desativar o mecanismo adaptativo separadamente. Se desejar manter o recurso semi-sync sempre ativo, defina innodb_polar_wait_slave_reply_max_time com um valor maior. O mecanismo adaptativo utiliza esse parâmetro para detectar timeouts.

P4: O RPO é 0 quando a semi-sync não sofre reversão. Essa "reversão" é a mesma coisa que ocorre quando o mecanismo adaptativo desativa dinamicamente a semi-sync?

R4: São conceitos diferentes. "Sem reversão" significa que uma transação só é efetivada após seu redo log ter sido sincronizado na zona secundária. Nesse caso, um RPO de 0 é estritamente garantido. Contudo, o mecanismo adaptativo opera no nível de pacotes de rede, não no nível de transação. Quando o mecanismo adaptativo desativa dinamicamente a semi-sync, geralmente é porque múltiplas transações já foram efetivadas devido a timeouts de sincronização. Em outras palavras, mesmo com a semi-sync ativada e sem desativação pelo mecanismo adaptativo, o RPO não é estritamente 0. Algumas poucas transações podem ser efetivadas devido a timeouts de sincronização, embora seja um evento raro. Dessa forma, o recurso semi-sync garante que o RPO fique próximo de 0.