Durante o commit de uma transação grande, o ApsaraDB RDS for MySQL mantém um bloqueio de escrita enquanto transfere eventos do binary log do cache da sessão para um arquivo de binary log. Se o cache do binary log atingir dezenas de GB, esse bloqueio impede todas as solicitações de escrita e pode esgotar os recursos de I/O, deixando a instância sem resposta.
O recurso binlog cache free flush elimina esse gargalo ao converter arquivos temporários no cache do binary log diretamente em arquivos de binary log no momento do commit, em vez de ler e reescrever cada evento sob bloqueio. Isso reduz o tempo de commit de transações grandes, diminui o consumo de I/O e mantém a instância responsiva.
Pré-requisitos
Antes de começar, verifique se:
Sua instância RDS executa MySQL 8.0 ou MySQL 5.7
A versão secundária do mecanismo é 20240731 ou posterior
Para verificar a versão secundária do mecanismo, faça login no console do ApsaraDB RDS e acesse a página Basic Information. Na seção Configuration Information, verifique se o botão Upgrade Kernel Version está visível. Caso esteja, clique nele para visualizar e atualizar a versão secundária do mecanismo. Se o botão não aparecer, a instância já está na versão secundária mais recente. Para mais informações, consulte Atualizar a versão secundária do mecanismo.
Ativar e configurar o recurso
Ativar o recurso
Execute o comando a seguir para ativar o binlog cache free flush:
SET GLOBAL loose_binlog_cache_free_flush = on;A alteração entra em vigor imediatamente. Não é necessário reiniciar a instância.
Verificar se o recurso está ativo
SHOW GLOBAL VARIABLES LIKE 'loose_binlog_cache_free_flush';Ajustar o limiar
O parâmetro loose_binlog_cache_free_flush_limit_size define o tamanho mínimo dos dados do binary log que aciona a conversão. O valor padrão é 256 MB, ou seja, apenas transações cujos dados do binary log excedem 256 MB utilizam o caminho de free-flush.
Para aplicar a otimização a transações menores, reduza o limiar:
SET GLOBAL loose_binlog_cache_free_flush_limit_size = <size-in-bytes>;Desativar o recurso
SET GLOBAL loose_binlog_cache_free_flush = off;Parâmetros
|
Parâmetro |
Padrão |
Descrição |
|
|
|
Ativa ou desativa o recurso. Variável global do sistema. Entra em vigor imediatamente sem reiniciar a instância. Valores válidos: |
|
|
|
Limiar que aciona a conversão. Quando os dados do binary log de uma transação ultrapassam esse valor, os arquivos temporários no cache do binary log são convertidos em arquivos de binary log no momento do commit. Faixa de valores: 20971520–18446744073709551615 bytes. |
Como funciona
Cache do binary log
Cada sessão possui seu próprio cache do binary log, composto por espaço em memória (limitado por binlog_cache_size) e arquivos temporários em disco. Quando os eventos de uma transação excedem o limite de memória, eles são transferidos para um arquivo temporário.
No momento do commit, o mecanismo lê todos os eventos do cache, atualiza a posição final e o checksum e os grava no arquivo de binary log sob um bloqueio de escrita. Esse bloqueio garante a gravação ininterrupta dos eventos, mas impede outras transações durante toda a duração da transferência.
Impacto da escrita de binary log em transações grandes
Quando o cache do binary log de uma transação atinge dezenas de GB, sua transferência no momento do commit causa dois problemas:
Bloqueio de solicitações de escrita: O bloqueio de escrita persiste durante toda a transferência, impedindo que outras transações realizem escritas.
Esgotamento de I/O: A grande escrita sequencial consome recursos de I/O e pode deixar a instância sem resposta.
Como o binlog cache free flush resolve isso
O AliSQL otimiza o mecanismo de cache do binary log para permitir a conversão direta dos arquivos temporários no cache em arquivos de binary log. Duas alterações tornam isso possível:
Espaço reservado no cabeçalho: Ao gravar eventos no arquivo temporário, o sistema reserva um espaço no início para os cabeçalhos do arquivo de binary log. Quando o arquivo temporário é convertido em arquivo de binary log, esse espaço reservado é preenchido com os cabeçalhos necessários, sem necessidade de uma escrita separada.
Posições finais pré-calculadas: Cada evento calcula sua posição final com base no tamanho do espaço reservado, de modo que as posições já estejam corretas após a conversão.
Conteúdo do arquivo de binary log convertido
No commit de uma transação grande, o espaço reservado no início do arquivo temporário é preenchido com os seguintes dados antes da conversão:
|
Dados |
Descrição |
|
Cabeçalho do arquivo |
O magic number de 4 bytes |
|
Eventos de cabeçalho |
O evento de descrição de formato e o evento anterior de identificador global de transação (GTID) |
|
Evento vazio |
Um evento do tipo ignorável que preenche qualquer espaço reservado restante |
|
Evento GTID |
O GTID da transação em commit, gerado no momento do commit |
O restante do arquivo mantém os eventos originais da transação: eventos de consulta, eventos de mapeamento de tabela, eventos baseados em linha e eventos XID.
Diferenças em relação a um arquivo de binary log comum
Os arquivos de binary log convertidos diferem dos arquivos comuns em dois aspectos:
Contêm um evento vazio (tipo ignorável) que ocupa o espaço reservado restante.
O checksum fica desativado por padrão.
O recurso binlog cache free flush não altera o formato do arquivo de binary log. A replicação e as ferramentas de terceiros não são afetadas.
Efeitos da otimização
A figura compara os tempos de commit de transações grandes em instâncias que usam Enterprise SSDs (ESSDs) de nível de desempenho 1 (PL1) e Premium Local SSDs, com o recurso ativado e desativado. Ativar o binlog cache free flush reduz o tempo de commit e resolve tanto o esgotamento de recursos de I/O quanto a longa duração do bloqueio de escrita.