Como soluciono problemas que fazem com que minha réplica de leitura do Aurora atrase e reinicie?

Resolução

Observação: a resolução a seguir se aplica aos clusters do Aurora em uma única região da AWS e aos clusters primários do Global Database, não aos clusters secundários do Global Database.

Meça o AuroraReplicaLag

As réplicas do Aurora se conectam ao mesmo volume de armazenamento da instância do gravador. O Aurora grava as alterações de forma síncrona no volume de armazenamento compartilhado, mas replica as alterações de forma assíncrona nas instâncias do leitor. Para consistência de leitura, o Aurora invalida os dados armazenados em cache na memória relacionados à alteração. O cache de dados inclui o grupo de buffers ou o cache da página.

Em alguns casos, pode ocorrer um atraso quando você propaga as alterações nas instâncias do leitor. O atraso aparece como um aumento na métrica AuroraReplicaLag no Amazon CloudWatch que pode causar reinicializações, e é possível receber a seguinte mensagem de erro:

"Read Replica has fallen behind the master too much. Restarting".

Na edição do Amazon Aurora compatível com o MySQL, execute a seguinte consulta na tabela INFORMATION_SCHEMA.REPLICA_HOST_STATUS para medir o AuroraReplicaLag:

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

Exemplo de saída:

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

Na edição do Amazon Aurora compatível com o PostgreSQL, execute a seguinte consulta para obter a função aurora_replica_status() e filtrar os resultados:

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

Exemplo de saída:

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

Certifique-se de que todas as instâncias no cluster tenham a mesma especificação

Se uma instância de leitor tiver uma configuração de classe de instância de banco de dados menor do que uma instância de banco de dados de gravador, o número de alterações poderá ser muito grande. Assim, a instância do leitor não pode invalidar no cache. Para evitar esse problema, é uma prática recomendada manter a mesma especificação para todas as instâncias de banco de dados no cluster do Aurora.

Monitore sessões usando métricas e Monitoramento aprimorado

Quando você está executando várias sessões ao mesmo tempo, uma instância de leitor pode ficar atrasada. Uma réplica do Aurora pode aplicar lentamente as alterações necessárias do gravador devido à falta de recursos disponíveis. Para verificar se há atraso, veja as métricas CPUUtilization, DBConnections e NetworkReceiveThroughput. Também é possível ativar o Monitoramento aprimorado com uma granularidade de 1 ou 5 segundos para obter o uso de recursos no leitor. Ou ative o Insights de Performance e use o Database Insights para visualizar o workload do leitor. Para o Aurora compatível com PostgreSQL, é possível usar a métrica ReadIOPS.

Importante: o Insights de Performance chegará ao fim de sua vida útil em 30 de junho de 2026. É possível fazer o upgrade para o modo Avançado do Database Insights antes de 30 de junho de 2026. Se você não fizer o upgrade, os clusters de banco de dados que usam o Insights de Performance usarão como padrão o modo Padrão do Database Insights. Somente o modo Avançado do Database Insights oferecerá suporte a planos de execução e análises sob demanda. Se seus clusters usarem como padrão o modo Padrão, talvez você não consiga usar esses recursos no console. Para ativar o modo Avançado, consulte Ativação do modo Avançado do Database Insights para Amazon RDS e Ativação do modo Avançado do Database Insights para Amazon Aurora.

Use o CloudWatch para visualizar a atividade de gravação

Um aumento repentino na atividade de gravação em um cluster de produção que já tem muita gravação pode causar uma sobrecarga na instância de banco de dados do gravador. A sobrecarga pode causar atrasos nas instâncias do leitor. Use o CloudWatch para visualizar as métricas DMLThroughput, DDLThroughput e Queries que mostram picos repentinos. Para o Aurora compatível com PostgreSQL, veja a métrica WriteThroughput.

Solucionar problemas de transações de longa duração para o Aurora compatível com MySQL

O mecanismo MySQL InnoDB usa o controle de simultaneidade de várias versões (MVCC) por padrão. Portanto, você deve rastrear todas as alterações nas linhas que ocorreram durante toda a duração de uma transação. Depois que as transações de longa duração são concluídas, começa um pico de atividade das threads de limpeza. A limpeza repentina pode fazer com que uma réplica do Aurora atrase devido ao volume do backlog que as transações de longa duração criam.

Para o Aurora compatível com MySQL, verifique a métrica RollbackSegmentHistoryListLength no CloudWatch para ver o pico na limpeza. É possível executar o comando SHOW ENGINE INNODB STATUS para visualizar a limpeza. Ou execute a seguinte consulta:

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Exemplo de saída:

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

Configure os alarmes do CloudWatch para monitorar RollbackSegmentHistoryListLength para garantir que não alcance um número alto. É uma prática recomendada evitar transações de longa duração em bancos de dados relacionais.

Evite breves interrupções na rede

Embora sejam raras, podem ocorrer falhas transitórias na comunicação de rede entre as instâncias do gravador e do leitor, ou entre uma instância e a camada de armazenamento do Aurora. As instâncias do leitor podem atrasar ou reiniciar devido a uma breve interrupção na rede. A réplica do Aurora também pode atrasar porque um grande número de alterações sobrecarregou a largura de banda da rede da instância. Para evitar esse problema, é uma prática recomendada modificar o tamanho da instância de banco de dados para um tamanho que possa lidar com o número de alterações.

Informações relacionadas

Adicionar réplicas do Aurora a um cluster de banco de dados

Replicação com o Amazon Aurora MySQL

Monitorar métricas em um cluster do Amazon Aurora

Métricas no nível da instância do Amazon Aurora