Como posso resolver problemas comuns ao usar réplicas de leitura no Aurora?

5 minuto de leitura
0

Tenho uma instância de banco de dados do Amazon Aurora MySQL Edition compatível e estou tendo problemas ao usar réplicas de leitura. Quero solucionar esses problemas.

Resolução

Promover uma réplica de leitura do Aurora

Para promover outra instância de réplica de leitura como instância de gravador, execute um failover manual.

Conclua as seguintes etapas:

  1. Abra o console do Amazon Relational Database Service (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 automaticamente fará o failover para uma instância de réplica de leitura. Vários motivos podem fazer com que uma instância do gravador fique indisponível, como contenção de recursos e atividades de manutenção.

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

Você também pode 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 recém-promovido funciona como um cluster de banco de dados independente e gerencia as operações de leitura e gravação.

Meça o atraso na 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 atraso mínimo na replicação. No entanto, em alguns cenários, você pode observar um ligeiro aumento no atraso dos leitores.

Observação: as réplicas entre regiões usam replicação lógica. Alterar e aplicar 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 têm um atraso típico de menos de um segundo.

Para medir o atraso na replicação, use as seguintes métricas do Amazon CloudWatch:

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

Melhorar o desempenho da replicação

Para melhorar o atraso na replicação, execute as seguintes ações:

  • 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. Para evitar cargas de trabalho pesadas nas instâncias do leitor, é uma prática recomendada tornar todas as instâncias em um cluster do mesmo tamanho.
    Observação: se houver uma carga de trabalho pesada 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.
  • Se transações de longa duração estiverem em andamento, poderá ocorrer um atraso na réplica nos leitores. Para evitar atrasos na réplica, execute suas transações em lotes menores e execute confirmações com frequência.

Para obter informações sobre como usar a replicação nativa do MySQL baseada em log binário para solucionar problemas de atraso na réplica, consulte Visão geral do backup e da restauração de um cluster de banco de dados do Aurora.

Solucionar problemas de alto atraso de replicação

Você pode verificar o alto atraso de replicação na métrica AuroraReplicaLag do CloudWatch. Um alto atraso de replicação pode fazer com que a instância do leitor seja reiniciada. Para evitar a reinicialização frequente de uma instância de leitor devido ao alto atraso de replicação, consulte Por que minha réplica de leitura do Amazon Aurora ficou para trás e reinicia?

Configurar a replicação baseada em GTID

O Aurora não usa a replicação nativa de binlogs para replicar dados e ler instâncias de réplica. Você não pode usar identificadores de transações globais (GTID) para replicar dados entre instâncias no mesmo cluster. No entanto, você pode configurar a replicação baseada em GTID em determinados cenários. 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.

Observação: você pode configurar a replicação baseada em GTID entre um cluster do MySQL e um cluster do Aurora do Amazon RDS e entre clusters do Aurora. A origem precisa ser um mestre externo. Certifique-se de habilitar o registro binário na origem antes de iniciar o processo de replicação.

Para obter mais informações sobre o GTID, consulte GTID format and storage 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

AWS OFICIAL
AWS OFICIALAtualizada há 8 meses