Otimizar a replicação de logs binários para Aurora MySQL - Amazon Aurora
Replicação de logs binários de vários threadsOtimizar a replicação de binlog (Aurora MySQL 2,10 e posteriores)Otimizar a replicação de log binário (Aurora MySQL versão 2 até a versão 2.09)

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.

dica

Esta discussão presume que você esteja familiarizado com o mecanismo de replicação de log binário do MySQL e como funciona. Para obter informações anteriores, consulte Implementação de replicação na documentação do 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 operador SQL são gerenciados por um thread coordenador. Os eventos de log binário são aplicados em paralelo sempre que possível.

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.

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 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.

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.

A configuração ideal depende 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:

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

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.

Também é possível usar esse parâmetro como uma variável global, em que n é o número de threads de operadores paralelos:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Otimizar a replicação de binlog (Aurora MySQL 2,10 e posteriores)

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.

nota

Essa memória usada para esse recurso é independente da configuração binlog_cache do MySQL.

Esse recurso não se aplica a instâncias de banco de dados do Aurora que usam as classes de instância db.t2 e db.t3.

Você não precisa ajustar nenhum parâmetro de configuração para ativar essa otimização. Especificamente, se você ajustar 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 no Aurora MySQL 2.10 e posteriores.

As variáveis de status aurora_binlog_io_cache_reads e aurora_binlog_io_cache_read_requests estão disponíveis no Aurora MySQL 2.10 e posteriores. Essas variáveis de status ajudam você a monitorar a frequência com que os dados são lidos do cache de E/S do binlog.

  • aurora_binlog_io_cache_read_requests: mostra o número de solicitações de leitura de E/S para binlog provenientes do cache.

  • aurora_binlog_io_cache_reads: mostra o número de leituras de E/S para binlog que recuperam informações do cache.

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.

Otimizar a replicação de log binário (Aurora MySQL versão 2 até a versão 2.09)

Para otimizar a replicação de log binário para Aurora MySQL, ajuste os seguintes parâmetros de otimização no nível do cluster. Esses parâmetros ajudam você a especificar o equilíbrio correto entre a latência na instância de origem do log binário e o atraso de replicação.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

nota

Para clusters compatíveis com o MySQL 5.7, você pode usar esses parâmetros no Aurora MySQL versão 2 até a versão 2.09.*. No Aurora MySQL 2.10.0 e posteriores, esses parâmetros são substituídos pela otimização do cache de E/S de binlog e você não precisa usá-los.

Visão geral do grande buffer de leitura e otimizações de rendimento máximo

Você pode observar performance reduzida da replicação de log binário quando o thread de despejo de log binário acessa o volume do Aurora cluster enquanto o cluster processa um número elevado de transações. Você pode usar os parâmetros aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds e aurora_binlog_read_buffer_size para ajudar a minimizar esse tipo de contenção.

Suponha uma situação em que aurora_binlog_replication_max_yield_seconds está definido como maior que 0, e o arquivo de log binário atual do thread de despejo está ativo. Nesse caso, o thread de despejo de log binário aguarda até um número específico de segundos para que o arquivo de binlog atual seja preenchido por transações. Esse período de espera evita a disputa que pode surgir da replicação de cada evento de log binário individualmente. No entanto, isso aumenta o atraso da réplica para réplicas de log binário. Essas réplicas podem ficar atrás da origem pelo mesmo número de segundos que a configuração de aurora_binlog_replication_max_yield_seconds.

O arquivo de log binário atual significa o arquivo de log binário que o thread de despejo está fazendo a leitura atualmente para executar a replicação. Consideramos que um arquivo de log binário está ativo quando o arquivo de log binário está atualizando ou aberto para ser atualizado por transações recebidas. Depois de Aurora MySQL preencher o arquivo de log binário ativo, o MySQL cria e muda para um novo arquivo de log binário. O arquivo de log de binário antigo fica inativo. Ele não é mais atualizado por transações recebidas.

nota

Antes de ajustar esses parâmetros, meça a latência e a taxa de transferência da transação ao longo do tempo. Você pode achar que a performance de replicação de log binário é estável e tem baixa latência, mesmo que haja contenção ocasional.

aurora_binlog_use_large_read_buffer

Se esse parâmetro for definido como 1, Aurora MySQL otimiza a replicação de log binário com base nas configurações dos parâmetros aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds. Se aurora_binlog_use_large_read_buffer for 0, Aurora MySQL ignora os valores dos parâmetros aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

Os threads de despejo de log binário com buffer de leitura maior minimizam o número de operações de E/S de leitura lendo mais eventos para cada E/S. O parâmetro aurora_binlog_read_buffer_size define o tamanho do buffer de leitura. O buffer de leitura grande pode reduzir a disputa de log binário para workloads que geram uma grande quantidade de dados de log binário.

nota

Este parâmetro só tem um efeito quando o cluster também tem a configuração aurora_binlog_use_large_read_buffer=1.

Aumentar o tamanho do buffer de leitura não afeta a performance da replicação de log binário. Os threads de despejo de log binário não esperam a atualização de transações para preencher o buffer de leitura.

aurora_binlog_replication_max_yield_seconds

Se a workload exigir baixa latência de transação e você pode suportar algum atraso de replicação, é possível aumentar o parâmetro de aurora_binlog_replication_max_yield_seconds. Esse parâmetro controla a propriedade de rendimento máximo da replicação de log binário no cluster.

nota

Este parâmetro só tem um efeito quando o cluster também tem a configuração aurora_binlog_use_large_read_buffer=1.

Aurora MySQL reconhece qualquer alteração no valor do parâmetro aurora_binlog_replication_max_yield_seconds imediatamente. Você não precisa reiniciar a instância de banco de dados. No entanto, quando você habilita essa configuração, o thread de despejo apenas começa a gerar resultados quando o arquivo de binlog atual atinge seu tamanho máximo de 128 MB e é alternado para um novo arquivo.

Parâmetros relacionados

Utilize os seguintes parâmetros de cluster de banco de dados para ativar a otimização de log binário.

Parâmetro Padrão Valores válidos Descrição
aurora_binlog_use_large_read_buffer 1 0, 1 Alterne para ativar o recurso de melhoria de replicação. Quando seu valor é 1, o thread de despejo de log binário usa aurora_binlog_read_buffer_size para a replicação do log binário; caso contrário, o tamanho do buffer padrão (8K) é usado. Não utilizado no Aurora MySQL versão 3.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Leia o tamanho do buffer usado pelo thread de despejo de log binário quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1. Não utilizado no Aurora MySQL versão 3.
aurora_binlog_replication_max_yield_seconds 0 0-36000

Para o Aurora MySQL versão 2.07.*, o valor máximo aceito é 45. Você pode ajustá-lo para um valor mais alto na versão 2.09 e em versões posteriores.

Para a versão 2, esse parâmetro só funciona quando o parâmetro aurora_binlog_use_large_read_buffer é definido como 1.

Habilitar o mecanismo de rendimento máximo para replicação de log binário

Você pode ativar a otimização de rendimento máximo de replicação de log binário da seguinte forma. Isso minimiza a latência para transações na instância de origem do log binário. No entanto, você pode ter maior atraso de replicação.

Para habilitar a otimização de binlog com rendimento máximo para um cluster do Aurora MySQL

  1. Crie ou edite um grupo de parâmetros de cluster de banco de dados usando as seguintes configurações de parâmetros:

    • aurora_binlog_use_large_read_buffer: ative um valor de ON ou 1.

    • aurora_binlog_replication_max_yield_seconds: especifique um valor maior que 0.

  2. Associe o grupo de parâmetro do cluster de banco de dados ao cluster de Aurora MySQL que funciona como a origem do log binário. Para isso, siga o procedimento em Grupos de parâmetros para Amazon Aurora.

  3. Confirme se a alteração do parâmetro entra em vigor. Para isso, execute a seguinte consulta na instância de origem do log binário. 

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    Sua saída deve ser similar à seguinte. 

    +---------------------------------------+-----------------------------------------------+
| @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
+---------------------------------------+-----------------------------------------------+
|                                     1 |                                            45 |
+---------------------------------------+-----------------------------------------------+

Desativar a otimização de rendimento máximo de replicação de log binário

Você pode desativar a otimização de rendimento máximo de replicação de log binário da seguinte forma. Isso minimiza o atraso de replicação. No entanto, você pode ter maior latência para transações na instância de origem do log binário.

Para desativar a otimização de rendimento máximo de um cluster de Aurora MySQL

  1. Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha aurora_binlog_replication_max_yield_seconds definido como 0. Para ter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte Grupos de parâmetros para Amazon Aurora.

  2. Confirme se a alteração do parâmetro entra em vigor. Para isso, execute a seguinte consulta na instância de origem do log binário. 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    Sua saída deve ser similar à seguinte. 

    +-----------------------------------------------+
| @@aurora_binlog_replication_max_yield_seconds |
+-----------------------------------------------+
|                                             0 |
+-----------------------------------------------+

Desativando o grande buffer de leitura

É possível desabilitar todo o recurso de buffer de leitura grande da seguinte maneira.

Para desativar o buffer de leitura de log binário grande para um cluster de Aurora MySQL

  1. Redefina o aurora_binlog_use_large_read_buffer para OFF ou 0.

    Certifique-se que o grupo de parâmetros de cluster de banco de dados associado ao cluster do Aurora MySQL tenha aurora_binlog_use_large_read_buffer definido como 0. Para ter mais informações sobre a definição de parâmetros de configuração usando grupos de parâmetros, consulte Grupos de parâmetros para Amazon Aurora.

  2. Na instância de origem do log binário, execute a seguinte consulta. 

    SELECT @@ aurora_binlog_use_large_read_buffer;

    Sua saída deve ser similar à seguinte. 

    +---------------------------------------+
| @@aurora_binlog_use_large_read_buffer |
+---------------------------------------+
|                                     0 |
+---------------------------------------+