Por que minha réplica de leitura do Amazon Aurora ficou para trás e reinicia?
Estou executando um cluster de banco de dados de produção do Amazon Aurora. Minha instância do leitor foi reiniciada com a mensagem de erro “A réplica de leitura ficou muito atrás da principal. Reiniciando o MySQL” ou “A réplica de leitura ficou muito atrás da principal. Reiniciando o postgres”.
Descrição resumida
O AuroraReplicaLag é uma medida de atraso em milissegundos ao replicar alterações da instância do gravador de banco de dados do Aurora para as instâncias do leitor em um cluster de banco de dados do Aurora. As réplicas do Aurora se conectam ao mesmo volume de armazenamento da instância do gravador. Para medir o atraso entre as instâncias do gravador e do leitor, use a métrica AuroraReplicaLag no Amazon CloudWatch.
Para um cluster de banco de dados do Aurora, a métrica AuroraReplicaLag indica o atraso do cache de dados da réplica do Aurora em comparação com a instância do gravador de banco de dados. O cache de dados inclui o grupo de buffers ou o cache da página. As alterações são gravadas de forma síncrona no volume de armazenamento compartilhado. No entanto, as alterações são replicadas de forma assíncrona nas instâncias do leitor, onde todos os dados armazenados em cache na memória relacionados à alteração são invalidados para fins de consistência de leitura. Em alguns casos, pode haver um atraso na propagação das alterações nas instâncias do leitor. Esse atraso aparece como um aumento na métrica AuroraReplicaLag no CloudWatch, o que pode levar a eventuais reinicializações.
Você pode medir metadados quase em tempo real sobre o AuroraReplicaLag:
Para a edição compatível com o Amazon Aurora MySQL, selecione na tabela INFORMATION_SCHEMA.REPLICA_HOST_STATUS:
mysql> 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; +---------------------+--------+-------------------+ | Instance_Identifier | Role | AuroraReplicaLag | +---------------------+--------+-------------------+ | myamscluster-aza-1 | writer | 0 | | myamscluster-azb-1 | reader | 5.150000095367432 | | myamscluster-aza-2 | reader | 5.033999919891357 | +---------------------+--------+-------------------+
Para a edição compatível com o Amazon Aurora PostgreSQL, chame a função aurora_replica_status() e filtre os resultados:
postgres=> 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(); server_id | role | aurorareplicalag -------------------+--------+------------------ myapgcluster-aza-1 | Reader | 19.641 myapgcluster-azb-1 | Reader | 19.752 myapgcluster-aza-2 | Writer | (3 rows)
**Observação:**a solução fornecida nesse artigo se aplica aos clusters primários de uma única região e do banco de dados global do Amazon Aurora, e não aos clusters secundários do banco de dados global.
Resolução
Certifique-se de que todas as instâncias no cluster tenham a mesma especificação
Se uma instância do leitor tiver uma configuração de classe de instância de banco de dados mais fraca do que uma instância do gravador de banco de dados, o volume de alterações poderá ser muito grande. Nesse caso, a instância do leitor não pode ser invalidada no cache e depois recuperada. Portanto, é recomendável que todas as instâncias de banco de dados no cluster do Aurora tenham a mesma especificação.
Monitore sessões usando métricas e Monitoramento Avançado
Uma instância do leitor pode sofrer atraso quando várias sessões estão sendo executadas ao mesmo tempo. Uma réplica do Aurora pode demorar em aplicar as alterações necessárias provenientes do gravador pela falta de recursos disponíveis. Você pode ver esse atraso em métricas como CPUUtilization, DBConnections e NetworkReceiveThroughput. Você também pode ativar o Monitoramento Avançado com uma granularidade de 1 ou 5 segundos para entender o uso de recursos no leitor. E pode usar o Insights de Performance para visualizar o workload. Além disso, somente para a edição compatível com o Aurora PostgreSQL, use a métrica ReadIOPS.
Visualize a atividade de gravação usando o CloudWatch
Um aumento repentino na atividade de gravação em um cluster de produção com muita gravação pode causar uma sobrecarga na instância do gravador de banco de dados. O estresse adicional causado pelo aumento pode fazer com que uma ou mais instâncias do leitor fiquem para trás. Você pode ver isso no CloudWatch, que mostra expansões repentinas das métricas DMLThroughput, DDLThroughput e Queries.
Para o Aurora PostgreSQL, você pode ver isso na métrica WriteThroughput.
Investigue o tamanho da lista de histórico (HLL) cada vez mais alto (compatível com o Aurora MySQL)
O mecanismo MySQL InnoDB incorpora o controle de simultaneidade de várias versões (MVCC) por padrão. Isso significa que você deve acompanhar todas as alterações que ocorreram em todas as linhas afetadas durante a duração de uma transação. Depois que as transações de longa duração são concluídas, começa um aumento na atividade do segmento de limpeza. Devido ao volume de backlogs criado por meio de transações de longa duração, a limpeza repentina pode fazer com que uma réplica do Aurora fique para trás.
Nas versões 1.19.2, 2.06 e posteriores, o Aurora MySQL inclui a métrica RollbackSegmentHistoryListLength. Você pode usar essa métrica no CloudWatch para ver essa limpeza. Isso também é visível na saída do SHOW ENGINE INNODB STATUS ou consultando o esquema de informações da seguinte forma:
mysql> select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len'; +----------------------------------+-------+ | RollbackSegmentHistoryListLength | COUNT | +----------------------------------+-------+ | trx_rseg_history_len | 358 | +----------------------------------+-------+ 1 row in set (0.00 sec)
Configure alarmes do CloudWatch para monitorar essa métrica para que ela não atinja um número excessivamente alto. É uma prática recomendada em bancos de dados relacionais evitar transações de longa duração.
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 ficar para trás ou serem reiniciadas devido a uma breve interrupção na rede. A réplica do Aurora também pode ficar para trás devido à saturação da largura de banda da rede da instância causado por um grande volume de alterações. É uma prática recomendada considerar o tamanho da instância de banco de dados e, portanto, seus recursos de rede, para evitar esse problema.
Informações relacionadas
Como adicionar réplicas do Aurora a um cluster de banco de dados
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 3 anos
- Como posso criar uma réplica de leitura para uma instância de banco de dados MySQL do Amazon Aurora?AWS OFICIALAtualizada há 2 anos