Come posso risolvere i problemi che causano il ritardo e il riavvio della mia replica di lettura Aurora?

Risoluzione

Nota: la seguente risoluzione si applica ai cluster Aurora in una singola Regione AWS e ai cluster primari di database globali, non ai cluster secondari di database globali.

Misura il valore AuroraReplicaLag

Le repliche Aurora si connettono allo stesso volume di archiviazione dell'istanza di scrittura. Aurora scrive le modifiche in modo sincrono nel volume di archiviazione condiviso ma replica in modo asincrono le modifiche nelle istanze di lettura. Per garantire la coerenza della lettura, Aurora invalida i dati memorizzati nella cache relativi alla modifica. La cache dei dati include il pool di buffer o la cache delle pagine.

In alcuni casi, può verificarsi un ritardo quando si propagano le modifiche tra le istanze di lettura. Il ritardo appare come un aumento della metrica AuroraReplicaLag in Amazon CloudWatch che può causare riavvii e potresti ricevere il seguente messaggio di errore:

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

Per Amazon Aurora compatibile con MySQL, esegui questa query sulla tabella INFORMATION_SCHEMA.REPLICA_HOST_STATUS per misurare 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;

Esempio di output:

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

Per Amazon Aurora compatibile con PostgreSQL, esegui questa query per ottenere la funzione aurora_replica_status() e filtrare i risultati:

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();

Esempio di output:

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

Assicurati che tutte le istanze del cluster abbiano le stesse specifiche

Se un'istanza di lettura ha una configurazione di classe di istanza database inferiore rispetto a un'istanza database di scrittura, il numero di modifiche potrebbe essere troppo elevato. Quindi l'istanza di lettura non può essere invalidata nella cache. Per evitare questo problema, è consigliabile mantenere le stesse specifiche per tutte le istanze database del cluster Aurora.

Monitora le sessioni utilizzando le metriche e Monitoraggio avanzato

Quando esegui più sessioni contemporaneamente, un'istanza di lettura può subire ritardi. Una replica Aurora potrebbe applicare lentamente le modifiche necessarie dell'istanza di scrittura perché mancano le risorse disponibili. Per verificare il ritardo, visualizza le metriche CPUUtilization, DBConnections e NetworkReceiveThroughput. Puoi anche attivare Monitoraggio avanzato con una granularità di 1 o 5 secondi per comprendere l'utilizzo delle risorse dell'istanza di lettura. Oppure attiva Performance Insights e utilizza Database Insights per visualizzare il carico di lavoro dell'istanza di lettura. Per Aurora compatibile con PostgreSQL, puoi utilizzare la metrica ReadIOPS.

Importante: Performance Insights giungerà al termine del suo ciclo di vita il 30 giugno 2026. Entro tale data puoi passare alla modalità Avanzata di Database Insights. Se non esegui l'aggiornamento, i cluster di database che utilizzano Approfondimenti sulle prestazioni passeranno automaticamente alla modalità Standard di Database Insights. Solo la modalità Avanzata di Database Insights supporta i piani di esecuzione e l'analisi on demand. Se i cluster dovessero passare automaticamente alla modalità Standard, potresti non essere in grado di utilizzare queste funzionalità sulla console. Per attivare la modalità Avanzata, consulta Attivazione della modalità avanzata di Database Insights per Amazon RDS e Attivazione della modalità avanzata di Database Insights per Amazon Aurora.

Utilizza CloudWatch per visualizzare l'attività di scrittura

Un improvviso picco dell'attività di scrittura in un cluster di produzione già ad alta intensità di scrittura può sovraccaricare l'istanza database di scrittura. Il sovraccarico può causare ritardi nelle istanze di lettura. Utilizza CloudWatch per visualizzare le metriche DMLThroughput, DDLThroughput e Queries che mostrano i picchi improvvisi. Per Aurora compatibile con PostgreSQL, visualizza la metrica WriteThroughput.

Risolvi i problemi relativi alle transazioni di lunga durata per Aurora compatibile con MySQL

Il motore MySQL InnoDB utilizza il controllo della concorrenza multivisione (MVCC) come impostazione predefinita. Pertanto, è necessario tenere traccia di tutte le modifiche alle righe che si sono verificate durante una transazione. Dopo il completamento delle transazioni di lunga durata, inizia un picco nell'attività del thread di eliminazione. L'eliminazione improvvisa può causare il ritardo di una replica Aurora a causa del volume del backlog creato dalle transazioni di lunga durata.

Nel caso di Aurora compatibile con MySQL, controlla la metrica RollbackSegmentHistoryListLength in CloudWatch per visualizzare il picco di eliminazione. Puoi eseguire il comando SHOW ENGINE INNODB STATUS per visualizzare l'eliminazione. Oppure esegui questa query:

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

Esempio di output:

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

Configura allarmi in CloudWatch per monitorare RollbackSegmentHistoryListLength per assicurarti che non raggiunga un valore elevato. È consigliabile per evitare transazioni di lunga durata nei database relazionali.

Evita brevi interruzioni di rete

Per quanto raramente, possono verificarsi errori di comunicazione di rete transitori tra le istanze di scrittura e di lettura o tra un'istanza e il livello di archiviazione Aurora. Le istanze di lettura possono subire ritardi o riavviarsi a causa di una breve interruzione di rete. La replica Aurora può ritardare anche perché un gran numero di modifiche ha sovraccaricato la larghezza di banda di rete dell'istanza. Per evitare questo problema, è consigliabile modificare la dimensione dell'istanza database in modo che sia in grado di gestire il numero di modifiche.

Informazioni correlate

Aggiunta di repliche di Aurora a un cluster di database

Replica con Amazon Aurora MySQL

Monitoraggio delle metriche in un cluster di database Amazon Aurora

Metriche a livello di istanza per Amazon Aurora