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

Breve descrição

O Amazon Aurora MySQL oferece suporte a réplicas de leitura que compartilham um volume subjacente comum com uma instância de banco de dados de gravador na mesma região da AWS. Se você alterar sua instância de banco de dados do gravador, as atualizações ficarão visíveis para as instâncias de réplica no cluster de banco de dados. Você também pode criar réplicas de leitura do MySQL entre regiões. Eles são implementados usando o mecanismo de replicação baseado em log binário do MySQL.

É uma prática recomendada usar réplicas do Aurora ao escalar as operações de leitura. Você faz isso reduzindo a workload de leitura do gravador. Em seguida, aumente a disponibilidade para lidar com eventos que retardam ou bloqueiam a escalabilidade.

Resolução

Como faço para promover uma réplica de leitura do Aurora?

Failover manual: execute um failover manual para promover outra instância de réplica de leitura como uma instância de gravador seguindo estas etapas:

1. Faça login no console do Amazon Relational Database Service (Amazon RDS).
2. No painel de navegação, escolha 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.

Failover automático: o Aurora realiza automaticamente o failover em uma instância de réplica de leitura se a instância do gravador ficar indisponível. Isso pode acontecer por vários motivos, incluindo contenção de recursos e atividades de manutenção. Se você tiver vários leitores, você pode dar um nível de 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 como um cluster de banco de dados independente. A replicação entre regiões é interrompida após você iniciar o processo de promoção. O cluster recém-promovido funciona como um cluster de banco de dados independente e lida com operações de leitura e gravação.

Como posso medir o atraso na replicação?

Como todas as instâncias de banco de dados Aurora em um único cluster de banco de dados compartilham um volume de dados comum, há um atraso mínimo na replicação. Normalmente, os tempos de atraso estão na casa dos 10 milissegundos. No entanto, você pode observar um ligeiro aumento do atraso dos leitores em algumas circunstâncias específicas.

Observação: as réplicas entre regiões usam replicação lógica e são influenciadas pela taxa de alteração/aplicação e pelos atrasos na comunicação de rede entre as regiões específicas selecionadas. As réplicas entre regiões que usam bancos de dados Aurora têm um atraso típico de menos de um segundo.

Você pode medir o atraso na replicação usando as seguintes métricas do Amazon CloudWatch:

• Use o AuroraReplicaLag para medir o atraso da réplica entre o nó do gravador e do leitor em milissegundos (mesma região).
• Use o AuroraBinLogReplicaLag para medir o atraso da réplica entre clusters de banco de dados do Aurora usando registros binários.

Como posso melhorar o desempenho da replicação?

Siga estas recomendações para melhorar o atraso da réplica:

• 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. É uma prática recomendada que todas as instâncias em um cluster tenham o mesmo tamanho para evitar qualquer sobrecarga de trabalho nas instâncias do leitor.
• Se houver uma carga de trabalho pesada no gravador, você poderá notar um atraso temporário na leitura da réplica. O atraso diminui depois que a instância do leitor alcança a instância do gravador.
• Se houver alguma transação de longa duração em andamento, você poderá observar 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 mais frequência.

Para obter mais informações sobre como solucionar o alto atraso na réplica usando a replicação nativa do MySQL baseada em binlog, consulte Visão geral do backup e da restauração de um cluster de banco de dados Aurora.

Posso usar um identificador de transação global (GTID)?

Um identificador de transação global é uma string exclusiva associada a uma transação em seu Commit. Um GTID é exclusivo em todos os servidores e as alterações são aplicadas no destino, com base no valor do GTID. Para obter mais informações, consulte a documentação do MySQL para conceitos de GTID.

O Aurora não usa a replicação nativa de binlogs para replicar dados e ler instâncias de réplica. Não é possível usar o 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 o uso da replicação baseada em GTID no Aurora MySQL, consulte o blog da AWS sobre GTID.

**Observação:**Você pode configurar a replicação baseada em GTID entre um cluster MySQL do Amazon RDS e um cluster do Aurora e entre os clusters do Aurora (supondo que a origem seja um mestre externo). Certifique-se de habilitar o registro binário na origem antes de iniciar o processo de replicação.

---

Informações relacionadas

Replicação com o Amazon Aurora

O que é o Amazon Aurora?