O RDS for MySQL otimiza a replicação paralela para eliminar o atraso de replicação durante o processamento de dados em lote. Esse recurso é especialmente útil ao executar operações de exclusão, organização ou importação em massa fora dos horários de pico.
Aplicabilidade
A instância de banco de dados deve atender a um dos seguintes requisitos de versão:
RDS for MySQL 8.4
RDS for MySQL 8.0 com versão secundária do mecanismo 20251130 ou posterior
Ativação
Para ativar esse recurso, defina o seguinte parâmetro global na instância primária ou em uma instância somente leitura.
Nome do parâmetro:
loose_optimize_replica_parallelismValor:
ONVigência: A configuração entra em vigor imediatamente. Não é necessário reiniciar a instância.
Contexto
Muitas aplicações executam operações de dados, como exclusão, organização e importação, fora dos horários de pico. Elas utilizam lotes pequenos com alta concorrência. Essa abordagem é rápida e permite ajustar o tamanho do lote e a concorrência para controlar o impacto no banco de dados.
Durante o processamento de dados em lote, dois tipos principais de transações coexistem na instância: transações de tamanho médio provenientes de jobs em lote (que geralmente processam milhares de linhas por transação) e transações pequenas decorrentes de operações comerciais regulares. Mesmo fora dos horários de pico, persiste algum tráfego de negócios normal. Esses dois tipos de transação são intercalados no arquivo binlog. Se múltiplas transações pequenas que modificam a mesma linha ficarem intercaladas entre duas transações de tamanho médio, as transações médias não poderão ser executadas simultaneamente.
Conforme ilustrado na figura acima, Trx2 e Trx5 são transações de tamanho médio de um processo em lote. Trx3 e Trx4 são transações pequenas de operações comerciais regulares que modificam a mesma linha. Quando a thread SQL despacha essas transações, Trx2 e Trx3 são despachadas normalmente. No entanto, Trx4 precisa aguardar o commit de Trx3 e de todas as transações anteriores antes que a thread SQL possa despachá-la. Isso atrasa o despacho de Trx5 até que Trx2 faça o commit, impedindo a aplicação paralela de Trx2 e Trx5.
Como resultado, a concorrência da réplica torna-se muito baixa durante o processamento de dados em lote. Em certos momentos, apenas uma única thread de trabalho permanece ativa. Isso reduz efetivamente a replicação ao desempenho de thread única e causa um atraso significativo.
Resultados
O teste a seguir utiliza a exclusão de dados em lote para demonstrar a melhoria. Um script sysbench de escrita exclusiva em thread única simulou pequenas transações em segundo plano, enquanto oito threads concorrentes excluíram dados em lotes de 5.000 linhas. As figuras acima mostram o atraso de replicação em uma instância somente leitura. Antes da ativação do recurso, o throughput da réplica era baixo e o atraso de replicação aumentava continuamente. Após a ativação, o throughput aumentou significativamente e o atraso de replicação diminuiu até a sincronização da réplica.
Funcionamento
Com essa otimização, pequenas transações conflitantes que aparecem entre transações de tamanho médio aguardam o commit das dependências em suas próprias threads de trabalho, em vez de aguardar na thread SQL. Isso evita que a thread SQL bloqueie o despacho de outras transações, permitindo a execução paralela de transações de tamanho médio sem conflitos.