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 Upgrade the minor engine version.

• 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 Set instance parameters.

• Configure o modo de replicação de dados da instância como replicação assíncrona. Para mais informações, consulte Query and modify the data replication mode.

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 significa que os dois parâmetros a seguir devem ser definidos como 1:

sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;

O MySQL padrão exige 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. Essa exigência reduz a eficiência do commit, impacto mais pronunciado em discos cloud.

Para melhorar a eficiência do commit de transações, o AliSQL introduziu o recurso Binlog in Redo. Ele é ativado ao definir o parâmetro persist_binlog_to_redo=ON e vem 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 juntos. 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 no 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 usa processamento em lote e um mecanismo de commit em grupo para mitigar a contenção de bloqueios causada pela alocação de GTID em cenários de alta concorrência. Essa abordagem reduz conflitos de bloqueio e garante alto desempenho.

Uma thread em segundo plano grava o arquivo de log binário de forma assíncrona e anexa 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 reproduzir 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, use a ferramenta XtraBackup fornecida pelo RDS para restaurar uma instância de disco local de alto desempenho para um banco de dados autogerenciado usando um arquivo de backup físico. Para instalar a ferramenta XtraBackup, consulte Tool preparation.

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 reiniciar a instância.

  Nota

  Para ativar este recurso, além de definir 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 definir parâmetros da instância, consulte Set instance parameters.

  • Para mais informações sobre como definir o modo de replicação de dados, consulte Query and modify the data replication mode.

  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 (milissegundos). Na maioria dos casos, o valor padrão é suficiente. As alterações neste parâmetro entram em vigor imediatamente sem reiniciar a instância.

Benchmarks de desempenho

• Ambiente de teste

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

  • Especificações da instância RDS: 32 núcleos, 128 GB de memória, disco cloud 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, com 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, portanto realiza commits com mais frequência. Em contraste, 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), realizando commits com menos frequência. Como resultado, a melhoria de desempenho para oltp_update_non_index é mais significativa do que para 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. Isso o torna eficaz para a maioria das cargas de trabalho de produção.

• Com mais 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.