Como resolvo problemas ao usar réplicas de leitura em minha instância de banco de dados compatível com o Aurora MySQL?

Resolução

Promova uma réplica de leitura compatível com o Aurora MySQL

Se a instância do gravador exigir uma reinicialização ou manutenção, execute um failover manual para promover uma réplica de leitura como uma instância do gravador.

Para realizar um failover manual, conclua as seguintes etapas:

1. Abra o console do Amazon RDS.
2. No painel de navegação, selecione Bancos de dados.
3. Escolha a instância do gravador para seu cluster de banco de dados Aurora.
4. Escolha Ações e, em seguida, Failover.

Se a instância do gravador ficar indisponível, o Aurora compatível com MySQL automaticamente fará o failover para uma instância de réplica de leitura. Uma instância do gravador pode ficar indisponível por vários motivos, como contenção de recursos ou atividade de manutenção.

Se você tiver vários leitores, especifique um nível de prioridade de promoção para cada instância do seu cluster. Quando a instância do gravador falha, o Aurora, compatível com MySQL, promove a réplica com a maior prioridade como o novo gravador.

Também é possível promover uma réplica do Aurora entre regiões da AWS como um cluster de banco de dados independente. Depois de iniciar o processo de promoção, a replicação entre regiões é interrompida. O cluster promovido funciona como um cluster de banco de dados independente e gerencia as operações de leitura e gravação.

Meça o atraso de replicação

Como todas as instâncias de banco de dados do Aurora em um cluster de banco de dados compartilham um volume de dados comum, há um pequeno atraso de replicação. No entanto, é possível enfrentar um ligeiro aumento no atraso dos leitores em alguns casos.

Observação: as réplicas entre regiões usam replicação de log binário. A alteração e aplicação de taxas e atrasos na comunicação de rede entre as regiões selecionadas podem afetar as réplicas entre regiões. As réplicas entre regiões que usam bancos de dados do Aurora MySQL têm um atraso típico de menos de 1 segundo.

Para medir o atraso de replicação, use as seguintes Amazon CloudWatch Metrics:

• A métrica AuroraReplicaLag mede o atraso da réplica entre o nó do gravador e do leitor em milissegundos na mesma região.
• A métrica AuroraBinlogReplicaLag mede o atraso da réplica entre clusters de banco de dados Aurora que usam logs binários.

Para obter mais informações sobre as métricas anteriores, consulte Métricas em Nível de instância para o Amazon Aurora.

Melhorar o desempenho da replicação

Realize as seguintes ações:

• Para evitar workloads pesadas nas instâncias do leitor, é uma prática recomendada fazer com que todas as instâncias em um cluster sejam do mesmo tamanho. Se a instância do leitor for menor do que a instância do gravador, o volume de alterações pode ser demais para o leitor acompanhar.
  Observação: se houver um workload pesado na instância do gravador, você poderá notar um atraso temporário na réplica de leitura. Depois que a instância do leitor alcança a instância do gravador, o atraso diminui.
• Para evitar atrasos de replicação quando transações de longa duração estiverem em andamento, execute suas transações em lotes menores e execute confirmações com frequência.

Para obter informações sobre como usar a replicação MySQL baseada em log binário nativo para solucionar problemas de atraso na réplica, consulte Problemas de replicação do Amazon Aurora MySQL.

Solucionar problemas de alto atraso de replicação

Use a métrica AuroraReplicaLag do CloudWatch para verificar o alto atraso de replicação. Um alto atraso de replicação pode fazer com que a instância do leitor seja reiniciada. Para resolver esse problema, consulte Por que minha réplica de leitura do Amazon Aurora ficou para trás e foi reiniciada?

Configurar a replicação baseada em GTID

O Aurora não usa a replicação nativa de log binário para replicar dados e ler instâncias de réplica. Não é possível usar identificadores de transações globais (GTID) para replicar dados entre instâncias no mesmo cluster. No entanto, é possível configurar a replicação baseada em GTID em alguns casos. Para obter mais informações sobre como usar a replicação baseada em GTID em ambientes compatíveis com o Aurora MySQL, consulte Amazon Aurora for MySQL compatibility now supports global transaction identifiers (GTIDs) replication (A compatibilidade do Amazon Aurora para MySQL agora oferece suporte a replicação de identificadores de transações globais [GTIDs]).

Nas versões 3.04 e posteriores compatíveis com o Aurora MySQL, a replicação de log binário multithread é ativada e replica_parallel_workers é definida como 4 por padrão. Como a replicação de log binário multithread está ativada, você deve aumentar a resiliência do seu banco de dados contra uma parada inesperada. É uma prática recomendada ativar a replicação de GTID em sua origem e permitir GTIDs na réplica.

Observação: é possível configurar a replicação baseada em GTID entre clusters do Aurora, bem como entre o Amazon Relational Database Service (Amazon RDS) para MySQL e um cluster do Aurora. A origem deve ser um servidor primário externo. Antes de iniciar o processo de replicação, certifique-se de ativar o registro em log binário na origem.

Para obter mais informações sobre o GTID, consulte GTID format and storage (Formato e armazenamento de GTID) no site do MySQL.

Informações relacionadas

Replicar clusters de banco de dados do Amazon Aurora MySQL entre regiões da AWS

Replicação com o Amazon Aurora