ApsaraDB RDS:Optimize large transaction commits

Recursos

Como a gravação no binlog é sequencial, uma transação grande leva muito tempo para gravar seus eventos no binlog e também bloqueia a confirmação de outras transações. Este recurso otimiza o mecanismo de gravação do binlog para a confirmação de transações grandes, tornando a velocidade de confirmação independente do número de eventos do binlog. Ele resolve os seguintes problemas comuns:

• Transações extremamente grandes bloqueiam a instância, impedindo a confirmação de outras transações.

• Transações grandes causam alto consumo de E/S, o que pode esgotar os recursos de E/S e tornar outras operações mais lentas, como as consultas.

• Transações grandes tornam mais lenta a execução de transações pequenas, resultando em um aumento nas conexões ativas e em flutuações de desempenho. Em casos graves, isso pode provocar uma falha em cascata e tornar a instância indisponível.

• A execução frequente de transações grandes causa instabilidade contínua no desempenho da sua carga de trabalho.

Pré-requisitos

A instância deve atender a um dos seguintes requisitos de versão:

• MySQL 8.4

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

• MySQL 5.7 com uma versão secundária do mecanismo 20240731 ou posterior.

  Nota

  Na página Basic Information, verifique a seção Configuration Information e localize o botão Upgrade minor engine version. Se o botão estiver disponível, atualize a instância. Se o botão não estiver disponível, a instância já está na versão secundária mais recente. Para mais detalhes, consulte Atualizar a versão secundária do mecanismo.

Uso

• Novas instâncias: o recurso binlog cache free flush vem ativado por padrão.

• Instâncias existentes: ative esse recurso definindo a variável global do sistema loose_binlog_cache_free_flush. A alteração entra em vigor imediatamente, sem necessidade de reiniciar a instância.

• Parâmetro relacionado:

  loose_binlog_cache_free_flush_limit_size: ao ativar o binlog cache free flush, o arquivo temporário é promovido a um arquivo de binlog se o binlog da transação exceder esse parâmetro. Isso ocorre na confirmação. Valor padrão: 256 MB. Intervalo de valores: 20971520 a 18446744073709551615 (unidade: bytes).

Análise do problema

Quando uma instância MySQL executa uma transação grande, o log de consultas lentas pode registrar atrasos incomuns para instruções de conclusão rápida, como COMMIT.

A tabela de análise de desempenho de SQL mostra os seguintes templates de SQL lento e suas principais métricas (banco de dados: sbtest):

• COMMIT ?: executado 2.104 vezes, duração média de 1,6375 s

• UPDATE t_large SET c=c+?: executado 989 vezes, duração média de 4,3019 s, duração máxima de 57,108 s, espera média de bloqueio de 1,7074 s

• DELETE FROM sbtest? WHERE id=?: executado 80 vezes, duração média de 1,6977 s

• UPDATE sbtest? SET c=? WHERE id=?: executado 62 vezes, duração média de 1,7872 s

O tempo máximo de execução e o tempo de espera de bloqueio do UPDATE t_large são significativamente maiores que os de outras instruções SQL, indicando que a transação grande é o gargalo de desempenho.

Esse problema é causado pela contenção de recursos no mecanismo de gravação sequencial do binlog. Uma transação grande em uma única thread leva muito tempo para gravar seu binlog, bloqueando a confirmação de outras transações e causando um atraso global e sequencial.

Durante um teste sysbench oltp_write_only, depois de executar uma operação grande de UPDATE que gera 512 MB de binlog a cada 5 segundos, observamos os seguintes efeitos:

• Sempre que o UPDATE grande é confirmado, as transações por segundo (TPS) caem drasticamente.

• O impacto no desempenho é proporcional ao tamanho do binlog: quanto maior o binlog gerado pela transação, maior será o impacto na latência de outras cargas de trabalho.

A figura a seguir ilustra o impacto de transações grandes em uma carga de trabalho em execução.

As operações relacionadas ao UPDATE:

CREATE TABLE t_large (a INT, b LONGTEXT) ENGINE = InnoDB;

# Insert a row with 256 MB of text. The resulting UPDATE generates 512 MB of binlog events.
INSERT INTO t_large VALUES (1, repeat('a', 256000000)); 

UPDATE t_large SET a = a + 1;

Efeitos da otimização

• Melhora significativa na estabilidade do TPS

  • Antes da otimização: a operação grande de UPDATE, executada a cada 5 segundos, causa flutuações severas no TPS.

  • Após a otimização (linha laranja): o impacto do UPDATE grande no TPS é praticamente eliminado.

  

• Sem flutuações significativas na latência

  • Como mostra a linha laranja (após a otimização), o impacto das operações de UPDATE de diferentes tamanhos na latência deixa de ser significativo.

  • Mesmo quando o tamanho do binlog excede 512 MB, a latência de confirmação de outras transações não sofre impacto significativo.

  

Como funciona

Cache do binlog

O cache do binlog é um espaço temporário no nível da sessão, usado para armazenar temporariamente eventos do binlog. Cada sessão tem seu próprio cache do binlog, composto por um cache de memória (buffer) e um arquivo temporário. O tamanho do cache de memória é controlado pelo parâmetro binlog_cache_size. Quando uma transação é grande o bastante para preencher o cache de memória, seus eventos são gravados no arquivo temporário.

Durante a execução da transação, os eventos gerados são armazenados temporariamente no cache do binlog. No momento da confirmação, o sistema lê esses eventos sequencialmente do cache do binlog. Em seguida, atualiza o end_pos (posição final) e a soma de verificação (checksum) de cada evento e os grava no arquivo de binlog. Para garantir que os eventos da transação sejam contíguos no arquivo de binlog, um bloqueio protege todo o processo. Enquanto uma transação mantém esse bloqueio para gravar no arquivo de binlog, o sistema bloqueia todas as outras transações em confirmação.

Problemas com gravações de binlog em transações grandes

A gravação desses eventos no arquivo de binlog durante a confirmação pode ser demorada e impactar severamente a instância de duas maneiras principais:

• O processo retém um bloqueio de gravação do binlog, impedindo qualquer gravação na instância durante a operação.

• A gravação consome muitos recursos de E/S. Em ambientes com capacidade de E/S limitada, isso pode travar toda a instância.

Otimização binlog cache free flush

O AliSQL redesenha os arquivos temporários usados pelo cache do binlog, permitindo sua promoção direta a arquivos de binlog. Quando esse recurso é ativado, confirmar uma transação grande promove seu arquivo temporário diretamente para um novo arquivo de binlog. Esse processo é extremamente rápido, consome recursos mínimos de E/S e elimina completamente os impactos negativos da gravação de binlogs para transações grandes.

Alterações no cache do binlog

Para permitir a promoção direta de um arquivo temporário do cache do binlog a um arquivo de binlog, o AliSQL modifica o uso do cache do binlog de duas maneiras principais:

• Ao gravar no arquivo temporário do cache do binlog, o sistema reserva um espaço no início do arquivo. Durante a promoção, esse espaço armazena os eventos de cabeçalho do binlog.

• Ao gravar no cache do binlog, o sistema calcula o end_pos de cada evento com base no tamanho desse espaço reservado.

Promoção do arquivo de binlog

Ao confirmar uma transação grande, o sistema promove seu arquivo temporário do cache do binlog diretamente para um novo arquivo de binlog. Durante esse processo, o sistema grava o cabeçalho do arquivo de binlog e os eventos de cabeçalho iniciais no espaço reservado. Esse espaço reservado contém quatro componentes principais:

• Cabeçalho do arquivo: o sistema grava um marcador de 4 bytes, [ 0xFE 'bin'], no início de cada arquivo de binlog para identificá-lo.

• Eventos de cabeçalho: incluem o evento Format description e o evento Previous gtid.

• Evento vazio: o sistema usa um tipo de evento existente e ignorável para preencher o espaço reservado restante.

• Evento Gtid: o sistema gera o GTID da transação grande durante a fase de confirmação e também grava seu evento no espaço reservado.

O conteúdo após o espaço reservado é composto pelos eventos do cache original do binlog, que normalmente incluem eventos Query, Table map, Row e Xid.

Um arquivo de binlog promovido por este recurso difere de um arquivo regular de duas maneiras:

• Ele contém um evento vazio (Empty event) adicional.

• A soma de verificação (checksum) deste arquivo vem desativada por padrão.

O recurso binlog cache free flush não altera o formato do binlog. A replicação e as ferramentas de terceiros que dependem de arquivos de binlog não sofrem impacto.