ApsaraDB RDS:Binlog parallel flush

Pré-requisitos

• A instância executa uma das seguintes versões do banco de dados:

  • MySQL 8.4

  • MySQL 8.0 com versão secundária do mecanismo 20230930 ou posterior.

    Nota

    Na página Basic Information, procure o botão Upgrade Minor Engine Version na seção Configuration Information. Se esse botão estiver visível, clique em e visualize a versão atual. Caso contrário, sua instância já está na versão mais recente. Para mais informações, consulte Upgrade Minor Engine Version.

• Não defina o parâmetro sync_binlog da instância como 1.

Contexto

No MySQL, cada transação deve gravar no log binário durante a fase de commit. Esse é um processo serial: uma transação só pode gravar no log binário após a conclusão da transação anterior, conforme mostrado na figura anterior.

Esse processo também consome muito tempo. Antes de gravar no log binário, todos os eventos armazenados no cache do log binário devem ser analisados, as somas de verificação (checksums) e as posições do log devem ser preenchidas, e um evento GTID deve ser gerado. Somente então esses eventos podem ser gravados no arquivo de log binário. Esse processo serial e demorado cria um gargalo significativo para o desempenho de gravação da instância. Para resolver esse gargalo, o AliSQL inclui a otimização Binlog Parallel Flush.

Detalhes da otimização

Buffer do log binário

O AliSQL aprimora a lógica padrão ao introduzir um buffer de log binário. Após a alocação das posições, várias threads podem gravar eventos do log binário no buffer do log binário em paralelo. Em seguida, uma thread de backend grava o conteúdo do buffer do log binário no arquivo de log binário. Esse design permite que etapas anteriormente seriais — como análise, preenchimento de valores de checksum e posição do log, e geração de eventos GTID — sejam executadas em paralelo. Isso alivia significativamente o gargalo de desempenho ao gravar logs binários durante os commits de transações.

Commit de grupo paralelo

No MySQL, as transações gravam no log binário e no redo log em grupos durante a fase de commit. Essa técnica, conhecida como group commit, mescla operações de E/S para melhorar o desempenho. Essa otimização mantém o conceito de group commit e o integra ao recurso Binlog Parallel Flush, conforme ilustrado na figura a seguir.

Com a otimização Binlog Parallel Flush, cada transação aloca serialmente um GTID e espaço no buffer do log binário. Posteriormente, vários grupos podem gravar no buffer do log binário em paralelo. Após a persistência do redo log e a conclusão da gravação no log binário pela thread de backend, o sistema faz o commit de todo o grupo de transações.

Persistência do log binário

Com a otimização Binlog Parallel Flush, uma thread de backend persiste periodicamente o arquivo de log binário. Por padrão, isso ocorre uma vez por segundo.

Parâmetros

loose_binlog_parallel_flush

Essa variável global do sistema ativa ou desativa o recurso Binlog Parallel Flush. Valores válidos: on ou off. As alterações nesse parâmetro entram em vigor imediatamente, sem a necessidade de reiniciar a instância.

Impacto no desempenho

Ambiente de teste

O teste comparou o desempenho em quatro especificações diferentes de instâncias do ApsaraDB RDS for MySQL, conforme detalhado na tabela a seguir.

Configurações de parâmetros

A instância de teste usa um modelo de parâmetros de alto desempenho; defina dois parâmetros relacionados ao desempenho como sync_binlog = 1000 e innodB_flush_log_at_trx_commit = 2.

Script de teste

O teste de desempenho usou o script oltp_update_non_index do SysBench. O conjunto de dados de teste consistiu em 100 tabelas, cada uma com 100.000 linhas.

Resultados do teste

Os resultados do teste são mostrados na figura a seguir. Em cargas de trabalho de alta concorrência, o recurso Binlog Parallel Flush oferece uma melhoria significativa de desempenho em comparação com a implementação padrão do MySQL. O ganho de desempenho de pico fica entre 10% e 30%.