Perché la mia replica di lettura di Amazon Aurora è rimasta indietro e si è riavviata?

5 minuti di lettura
0

Sto utilizzando un cluster Amazon Aurora database di produzione. La mia istanza di lettura è stata riavviata con il messaggio di errore "Read Replica è troppo indietro rispetto al master. Il riavvio di MySQL" o "Read Replica è rimasto troppo indietro rispetto al master. Riavvio di postgres."

Breve descrizione

AuroraReplicaLag è una misura del ritardo in millisecondi durante la replica delle modifiche dall'istanza Aurora DB di scrittura alle istanze di lettura in un cluster Aurora DB. Le repliche Aurora si connettono allo stesso volume di archiviazione dell'istanza di scrittura. Per misurare il ritardo tra le istanze Writer e Reader, utilizza la metrica AuroraReplicaLag in Amazon CloudWatch.

Per un cluster Aurora DB, la metrica AuroraReplicaLag indica il ritardo nella cache dei dati di Aurora Replica rispetto all'istanza DB di scrittura. La cache dei dati include il pool di buffer o la cache delle pagine. Le modifiche sono scritte in modo sincrono nel volume di archiviazione condiviso. Però, le modifiche vengono replicate in modo asincrono sulle istanze del lettore, dove vengono invalidati tutti i dati memorizzati nella cache e relativi alla modifica per garantire la coerenza della lettura. In alcuni casi, può verificarsi un ritardo nella propagazione delle modifiche tra le istanze del lettore. Questo ritardo appare come un aumento della metrica AuroraReplicaLag in CloudWatch, che può comportare eventuali riavvii.

Puoi misurare i metadati quasi in tempo reale su AuroraReplicaLag:

Per l'edizione compatibile con Amazon Aurora MySQL, seleziona dalla tabella 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 |
+---------------------+--------+-------------------+

Per l'edizione compatibile con Amazon Aurora PostgreSQL, chiama la funzione aurora_replica_status () e filtra i risultati:

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)

Nota: la soluzione fornita in questo articolo si applica ai cluster primari Amazon Aurora a singola regione e Global Database, non ai cluster secondari di Global Database.

Risoluzione

Assicurati che tutte le istanze del cluster abbiano le stesse specifiche

Se un'istanza reader ha una configurazione della classe di istanza DB più debole rispetto a un'istanza DB writer, il volume delle modifiche potrebbe essere troppo grande. In questo caso, l'istanza del lettore non può essere invalidata nella cache e quindi recuperare. Pertanto, è consigliabile che tutte le istanze database nel cluster Aurora abbiano le stesse specifiche.

Monitora le sessioni utilizzando metriche e monitoraggio avanzato

Un'istanza reader può subire ritardi quando si eseguono più sessioni contemporaneamente. Una replica Aurora può essere lenta nell'applicare le modifiche necessarie provenienti dal programma di scrittura a causa della mancanza di risorse disponibili. Puoi vedere questo ritardo in metriche come CPUUtilization,DBConnections e NetworkReceiveThroughput. Puoi anche attivare Enhanced Monitoring con una granularità di 1 o 5 secondi per comprendere l'utilizzo delle risorse sul lettore. E puoi usare Performance Insights per visualizzarne il carico di lavoro. Inoltre, solo per la compatibilità con Aurora PostgreSQL, usa la metrica ReadiOps.

Visualizza l'attività di scrittura con CloudWatch

Un'improvvisa impennata dell'attività di scrittura in un cluster di produzione che già richiede molta scrittura può sovraccaricare l'istanza database di writer. Lo stress aggiuntivo causato dalla sovratensione può causare il ritardo di una o più istanze di lettura. Puoi vederlo in CloudWatch, che mostra picchi improvvisi dei parametri DMLThroughput, DDLThroughput e Queries.

Per Aurora PostgreSQL, puoi vederlo nella metrica WriteThroughput.

Analizza la History List Length (HLL) sempre più completa (compatibile con Aurora MySQL)

Il motore MySQL InnoDB incorpora il controllo della concorrenza multivisione (MVCC) come impostazione predefinita. Ciò significa che è necessario tenere traccia di tutte le modifiche apportate su tutte le righe interessate per tutta la durata di una transazione. Dopo il completamento delle transazioni a lungo termine, inizia un picco nell'attività del thread di eliminazione. A causa del volume di backlog creato attraverso transazioni a lungo termine, l'eliminazione improvvisa può far restare indietro una replica Aurora.

Nelle versioni 1.19.2, 2.06 e successive, Aurora MySQL include la metrica RollbackSegmentHistoryListLength. Puoi usare questa metrica in CloudWatch per visualizzare questa eliminazione. Si può vedere anche nell'output di SHOW ENGINE INNODB STATUS o interrogando lo schema delle informazioni come segue:

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)

Configura gli allarmi CloudWatch per monitorare questa metrica in modo che non raggiunga un numero troppo alto. È buona pratica nei database relazionali per evitare transazioni di lunga durata.

Prevenire brevi interruzioni di rete

Anche se rari, possono verificarsi errori di comunicazione di rete transitori tra le istanze writer e reader o tra un'istanza e il livello di archiviazione Aurora. Le istanze reader possono rimanere indietro o riavviarsi a causa di una breve interruzione della rete. L'replica di Aurora può anche rimanere indietro a causa della saturazione della larghezza di banda di rete dell'istanza a causa di un grande volume di modifiche. È consigliabile considerare le dimensioni dell'istanza database e quindi le relative capacità di rete per evitare questo inconveniente.


Informazioni correlate

Aggiungere repliche Aurora a un cluster di database

Replica a master singolo con Amazon Aurora MySQL

Monitoraggio delle metriche in un cluster Amazon Aurora

AWS UFFICIALE
AWS UFFICIALEAggiornata un anno fa