ApsaraDB RDS:Binlog in Redo

Pré-requisitos

• Versão do banco de dados:

  • MySQL 8.4

  • MySQL 8.0: A versão secundária do mecanismo deve ser 20200430 ou posterior. Para atualizar a versão secundária do mecanismo da instância, consulte Atualize a versão secundária do mecanismo.

• Defina o parâmetro sync_binlog da instância como 1 e o parâmetro binlog_order_commits como OFF. Para mais informações, consulte Defina parâmetros da instância.

• Configure o modo de replicação de dados da instância como replicação assíncrona. Para mais informações, consulte Consultar e modifique o modo de replicação de dados.

Informações básicas

Em cenários críticos de MySQL, para garantir a segurança dos dados, o log binário e o redo log devem ser liberados sincronamente para o disco quando uma transação é confirmada. Isso exige que os dois parâmetros a seguir estejam definidos como 1:

sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;

O MySQL padrão requer duas operações síncronas de I/O em disco para cada commit de transação: uma para o log binário e outra para o redo log. Esse requisito reduz a eficiência do commit, impacto mais pronunciado em discos em nuvem.

Para melhorar a eficiência do commit de transações, o AliSQL introduziu o recurso Binlog in Redo, ativado ao definir o parâmetro persist_binlog_to_redo=ON e desativado por padrão. Quando uma transação é confirmada, esse recurso mescla o conteúdo do log binário com o redo log e os grava conjuntamente. Apenas uma operação síncrona de I/O é necessária para persistir o redo log, o que também libera os dados do log binário para o disco. Esse design elimina as duas operações separadas de I/O exigidas pelo MySQL padrão para o log binário e o redo log, reduzindo significativamente a latência e aumentando o throughput.

Além disso, o Binlog in Redo utiliza processamento em lote e um mecanismo de commit em grupo para mitigar a contenção de locks causada pela alocação de GTID em cenários de alta concorrência. Essa abordagem reduz conflitos de lock e garante alto desempenho.

Uma thread em segundo plano grava o arquivo de log binário de forma assíncrona, anexando dados em lotes periodicamente. Isso evita a pressão no sistema de arquivos causada por chamadas fsync em tempo real e melhora a eficiência geral de I/O. Mesmo que o banco de dados reinicie inesperadamente, o sistema restaura automaticamente a integridade do arquivo de log binário ao reexecutar os dados armazenados no redo log, garantindo a consistência dos dados.

O recurso Binlog in Redo não altera o formato do log binário. A replicação e ferramentas de terceiros baseadas no log binário não são afetadas.

Observações

Após ativar o recurso Binlog in Redo, para restaurar uma instância de disco local de alto desempenho para um banco de dados autogerenciado usando um arquivo de backup físico, use a ferramenta XtraBackup fornecida pelo RDS. Para instale a ferramenta XtraBackup, consulte Preparação da ferramenta.

Parâmetros

• persist_binlog_to_redo

  Ativa ou desativa o recurso Binlog in Redo. Esta é uma variável global do sistema. Valores válidos: on ou off. As alterações neste parâmetro entram em vigor imediatamente, sem necessidade de reiniciar a instância.

  Nota

  Para ative este recurso, além de defina persist_binlog_to_redo como on, defina binlog_order_commits como off e configure o modo de replicação de dados da instância como replicação assíncrona.

  • Para mais informações sobre como defina parâmetros da instância, consulte Defina parâmetros da instância.

  • Para mais informações sobre como defina o modo de replicação de dados, consulte Consultar e modifique o modo de replicação de dados.

  Se o parâmetro sync_binlog da instância não estiver definido como 1, o recurso Binlog in Redo não será ativado, mesmo que você configure os parâmetros anteriores. Nesse caso, recomendamos o uso do recurso Binlog Parallel Flush para otimizar o desempenho da instância.

• sync_binlog_interval

  Intervalo no qual os logs binários são persistidos de forma assíncrona. Esta é uma variável global do sistema e entra em vigor apenas quando persist_binlog_to_redo = on. O valor padrão é 50 ms. Na maioria dos casos, o valor padrão é suficiente. As alterações neste parâmetro entram em vigor imediatamente, sem necessidade de reiniciar a instância.

Benchmarks de desempenho

• Ambiente de teste

  • Servidor de aplicação: Uma instância ECS da Alibaba Cloud

  • Especificações da instância RDS: 32 núcleos, 128 GB de memória, disco em nuvem ESSD

  • Tipo de instância: Edição de Alta Disponibilidade (modo de replicação de dados: replicação assíncrona)

• Casos de teste

  Foram utilizados os seguintes casos de teste integrados do Sysbench:

  • oltp_update_non_index

  • oltp_write_only

• Resultados dos testes

  • oltp_update_non_index

    Com o Binlog in Redo ativado, o TPS aumenta significativamente em cenários de baixa concorrência e visivelmente em cenários de alta concorrência, apresentando menor latência.

    

  • oltp_write_only

    Com o Binlog in Redo ativado, o TPS aumenta substancialmente tanto em cenários de baixa quanto de alta concorrência, com menor latência.

    

Conclusões

• O caso de teste oltp_update_non_index contém apenas transações de instrução única, resultando em commits mais frequentes. Em contraste, o oltp_write_only contém transações de múltiplas instruções (duas instruções UPDATE, uma instrução DELETE e uma instrução INSERT), levando a commits menos frequentes. Consequentemente, a melhoria de desempenho para o oltp_update_non_index é mais significativa do que para o oltp_write_only.

• Com menos de 64 conexões simultâneas, o recurso Binlog in Redo melhora significativamente o desempenho e reduz a latência, tornando-o eficaz para a maioria das cargas de trabalho de produção.

• Acima de 256 conexões simultâneas, o recurso Binlog in Redo oferece maior desempenho de pico e menor latência, permitindo lidar melhor com picos repentinos de tráfego.