Em horários de pico, diversas cargas de trabalho atualizam bancos de dados com alta concorrência. Se o throughput de transações (TPS) na instância primária superar a capacidade das threads de I/O e SQL em uma instância réplica, pode ocorrer latência de replicação. Para resolver esse problema, o ApsaraDB RDS for MySQL otimiza a lógica de espera por locks entre as threads de I/O, SQL e worker, reduzindo a quantidade de esperas. Essa otimização elimina a latência de replicação em cenários de transações pequenas com alta concorrência.
Visão geral
Latência de replicação
Latência de replicação: Durante os horários de pico, muitas cargas de trabalho atualizam bancos de dados com alta concorrência. Se a instância primária aplicar transações com uma concorrência maior do que a instância réplica consegue acompanhar, o throughput de transações da réplica fica defasado, causando latência de replicação. Mesmo ao aumentar o número de worker threads ou ativar o Writeset feature, a concorrência de aplicação na réplica ainda pode ser insuficiente caso sua thread de I/O ou SQL atinja um gargalo de throughput.
Gargalos de throughput nas threads de I/O e SQL: A replicação multithread do MySQL utiliza três tipos de threads: a thread de I/O, a thread SQL e múltiplas worker threads. A thread de I/O recupera eventos de binlog da instância primária. A thread SQL distribui esses eventos de binlog para as worker threads, que então aplicam as transações em paralelo.
A coordenação entre as threads de I/O e SQL, bem como entre as threads SQL e worker, depende de operações de espera e notificação protegidas por locks. Cada evento de binlog exige um ciclo completo de lock e notificação. Uma única transação consiste em vários eventos de binlog. Por exemplo, no script de teste comum sysbench write_only, uma transação envolve a atualização de duas linhas, a inserção de uma linha e a exclusão de outra, gerando 11 eventos de binlog. Sob alta concorrência, esses locks frequentemente se tornam um gargalo de desempenho, limitando o throughput das threads de I/O e SQL.
Quando a thread de I/O ou SQL atinge um gargalo de throughput, as worker threads não recebem transações para aplicar em tempo hábil. Se a concorrência de aplicação das worker threads na instância réplica for inferior à concorrência da carga de trabalho na instância primária, ocorre latência de replicação.
Otimização de agrupamento de transações pequenas
Para otimizar a latência de replicação em transações pequenas com alta concorrência, o AliSQL introduz uma otimização de agrupamento de transações pequenas. Esse recurso agrupa os múltiplos eventos de binlog de uma transação pequena em um único ciclo de lock e notificação para as threads de I/O e SQL. Essa abordagem reduz significativamente o número de operações de lock, aumentando assim o throughput tanto das threads de I/O quanto das threads SQL.
Pré-requisitos
Para utilizar essa otimização, sua instância deve atender ao seguinte requisito:
Versão do mecanismo de banco de dados: Sua instância deve executar o ApsaraDB RDS for MySQL 8.0 com uma versão secundária do mecanismo igual ou superior a 20260228. Caso sua instância não atenda a esse requisito, Upgrade minor engine version ou Upgrade DB engine version.
Procedimento
Ative esse recurso configurando um parâmetro global nas suas instâncias primárias ou somente leitura:
Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em ID da instância.
No painel de navegação à esquerda, clique em Parameter settings.
-
Na aba Modifiable parameters, pesquise pelo parâmetro
loose_replica_package_transaction_limit_sizee configure seu valor.Descrição do parâmetro: O valor 0 desativa esse recurso. Quando o valor é maior que 0, transações com tamanho de binlog inferior a esse valor tornam-se elegíveis para a otimização.
Valores válidos: 0 a 1 MB.
Valor recomendado: 1 MB.
Clique em OK e, em seguida, clique em Submit parameters. Na caixa de diálogo, selecione um Effective period. A alteração do parâmetro entra em vigor imediatamente e não requer reinicialização da instância.
Resultados da otimização
Executamos o script sysbench write_only na instância primária com 128 threads concorrentes (80.000 transações por segundo ou TPS) para simular uma carga de escrita de pico durante 60 segundos. O teste apresentou os seguintes resultados:
Antes da otimização: A latência de replicação na instância réplica aumentava continuamente, e o throughput era muito baixo.
Após a otimização: A instância réplica não apresentou latência de replicação, e seu throughput quase dobrou.
