Otimizar a replicação de logs binários para Aurora MySQL

A seguir, você pode aprender como otimizar a performance da replicação de log binário e solucionar problemas relacionados no Aurora MySQL.

Replicação de logs binários de vários threads

Com a replicação de logs binários de vários threads, um thread SQL faz a leitura de eventos do log de retransmissão e coloca esses eventos em fila para que os threads de operador SQL sejam aplicados. Os threads de trabalho SQL são gerenciados pelo thread coordenador. Os eventos de log binário são aplicados em paralelo sempre que possível. O nível de paralelismo depende de alguns fatores, como versão, parâmetros, design do esquema e características da workload.

A replicação de logs binários de vários threads não é compatível com o Aurora MySQL versão 3, o Aurora MySQL versão 2.12.1 e posterior. Para que uma réplica de vários threads processe eficientemente eventos de log binário em paralelo, você deve configurar a origem para replicação de log binário de vários threads, e a origem deve usar uma versão que inclua as informações de paralelismo nos respectivos arquivos de log binário.

Quando uma instância de banco de dados do Aurora MySQL está configurada para utilizar a replicação de logs binários, por padrão a instância de réplica utiliza a replicação de um único thread para o Aurora MySQL versões anteriores a 3.04. Para habilitar a replicação de vários threads, atualize o parâmetro replica_parallel_workers para um valor superior a 1 no seu grupo de parâmetros personalizado.

Para o Aurora MySQL versão 3.04 e posterior, a replicação tem vários threads por padrão, com replica_parallel_workers definido como 4. É possível modificar esse parâmetro no grupo de parâmetros personalizado.

Para aumentar a resiliência do banco de dados contra paradas inesperadas, recomendamos habilitar a replicação de GTID na origem e permitir GTIDs na réplica. Para permitir a replicação de GTID, defina gtid_mode como ON_PERMISSIVE na origem e na réplica. Para obter mais informações sobre a replicação baseada em GTID, consulte Usar a replicação baseada em GTID.

As opções de configuração a seguir ajudam a ajustar a replicação de vários threads. Para obter informações sobre uso, consulte o tópico sobre Opções e variáveis de replicação e registro em log binário, no Guia de referência do MySQL. Para ter mais informações sobre a replicação de vários threads, consulte Improving the Parallel Applier with Writeset-based Dependency Tracking no blog do MySQL.

Os valores ideais dos parâmetros dependem de diversos fatores. Por exemplo, a performance da replicação de log binário é influenciada pelas características da workload do seu banco de dados e pela classe de instância de banco de dados na qual a réplica está sendo executada. Por isso, recomendamos testar completamente todas as alterações nesses parâmetros de configuração antes de aplicar novas configurações de parâmetros a uma instância de produção:

As características do esquema e da workload são fatores que afetam a replicação em paralelo. Os fatores mais comuns são apresentados a seguir.

No Aurora MySQL versão 3.06 e posterior, é possível melhorar o desempenho de réplicas de log binários ao replicar transações para tabelas grandes com mais de um índice secundário. Esse recurso introduz um grupo de threads para aplicar alterações de índice secundário em paralelo em uma réplica de log binário. O recurso é controlado pelo parâmetro aurora_binlog_replication_sec_index_parallel_workers do cluster de banco de dados, que controla o número total de threads paralelos disponíveis para aplicar as alterações do índice secundário. O parâmetro é definido como 0 (desabilitado) por padrão. A habilitação desse recurso não exige a reinicialização da instância. Para habilitar esse recurso, interrompa a replicação contínua, defina o número desejado de threads de operadores paralelos e inicie a replicação novamente.

Otimizar a replicação de log binário

No Aurora MySQL 2.10 e posteriores, o Aurora aplica automaticamente uma otimização conhecida como cache de E/S de binlog à replicação de log binário. Ao armazenar em cache os eventos de binlog confirmados mais recentemente, essa otimização foi projetada para melhorar a performance do processo de despejo de binlog, limitando o impacto nas transações em primeiro plano na instância de origem do binlog.

Você não precisa ajustar nenhum parâmetro de configuração para ativar essa otimização. Especificamente, se você tiver ajustado o parâmetro de configuração aurora_binlog_replication_max_yield_seconds para um valor diferente de zero em versões anteriores do Aurora MySQL, defina-o de volta para zero nas versões atualmente disponíveis.

As variáveis de status aurora_binlog_io_cache_reads e aurora_binlog_io_cache_read_requests ajudam você a monitorar a frequência com que os dados são lidos do cache de E/S do binlog.

A consulta SQL a seguir calcula a porcentagem de solicitações de leitura de binlog que aproveitam as informações armazenadas em cache. Nesse caso, quanto mais próxima a proporção for de 100, melhor ela é.

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

O recurso de cache de E/S de binlog também inclui novas métricas relacionadas aos processos de despejo de binlog. Processos de despejo são os processos criados quando novas réplicas de binlog são conectadas à instância de origem de binlog.

As métricas de processos de despejo são impressas no log do banco de dados a cada 60 segundos com o prefixo [Dump thread metrics]. As métricas incluem informações para cada réplica de binlog Secondary_id, como Secondary_uuid, nome do arquivo de binlog e a posição que cada réplica está lendo. As métricas também incluem Bytes_behind_primary, que representa a distância em bytes entre a origem da replicação e a réplica. Essa métrica mede o atraso do processo de E/S da réplica. Essa figura é diferente do lag do processo do aplicador SQL da réplica, que é representado pela métrica seconds_behind_master na réplica do binlog. Você pode determinar se as réplicas de binlog estão alcançando a origem ou ficando para trás, verificando se a distância diminui ou aumenta.

Log de retransmissão na memória

No Aurora MySQL versão 3.10 e posterior, o Aurora introduz uma otimização conhecida como log de retransmissão na memória para melhorar o throughput de replicação. Essa otimização melhora o desempenho de E/S do log de retransmissão ao armazenar em cache todo o conteúdo intermediário do log de retransmissão na memória. Desse modo, ela reduz a latência de confirmação ao minimizar as operações de E/S de armazenamento, pois o conteúdo do log de retransmissão pode ser facilmente acessado na memória.

Por padrão, o recurso de log de retransmissão na memória é habilitado automaticamente para cenários de replicação gerenciados pelo Aurora (como implantações azul-verde, replicação do Aurora para o Aurora e réplicas entre regiões) quando a réplica atende a qualquer uma destas configurações:

O recurso de log de retransmissão na memória é compatível com classes de instância maiores que t3.large, mas não está disponível em instâncias do Aurora Serverless. O buffer circular do log de retransmissão tem um tamanho fixo de 128 MB. Para monitorar o consumo de memória desse recurso, você pode executar a seguinte consulta:

SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';

O recurso de log de retransmissão na memória é controlado pelo parâmetro aurora_in_memory_relaylog, que pode ser definido em nível de cluster ou de instância de banco de dados. Você pode habilitar ou desabilitar esse recurso dinamicamente sem reiniciar a instância:

Exemplo:

CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;

Mesmo que aurora_in_memory_relaylog esteja definido como ON, em determinadas condições o recurso de log de retransmissão na memória ainda pode estar desabilitado. Para verificar o status atual do recurso, você pode usar o seguinte comando:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';

Se o recurso for desabilitado inesperadamente, você pode identificar o motivo executando:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';

Esse comando exibe uma mensagem explicando por que o recurso está desabilitado no momento.