Ritardo della replica

MySQL   |  PostgreSQL   |  SQL Server

Questa pagina descrive come risolvere i problemi e correggere il ritardo di replica per le repliche di lettura Cloud SQL.

Panoramica

Le repliche di lettura di Cloud SQL utilizzano gruppi di disponibilità AlwaysOn di SQL Server per la replica. Le modifiche vengono scritte nel log delle transazioni nell'istanza principale. L'istanza principale inoltra le transazioni a qualsiasi istanza di replica secondaria, dove vengono applicate le modifiche. La modalità di disponibilità utilizzata è Modalità di commit asincrono.

Il ritardo nella replica può verificarsi in alcuni scenari, ad esempio:

• L'istanza principale non riesce a inviare le modifiche alla replica abbastanza rapidamente.
• La replica non può ricevere le modifiche abbastanza rapidamente.
• La replica non riesce ad applicare le modifiche abbastanza rapidamente.

I primi due motivi sopra indicati possono essere monitorati con network_lag metric. Il terzo motivo viene osservato tramite la metrica seconds_behind_master. Una metrica seconds_behind_master elevata indica che la replica non può applicare le modifiche di replica abbastanza rapidamente. Queste metriche sono descritte nella sezione Monitorare il ritardo nella replica di seguito.

Ottimizza le query e lo schema

Questa sezione suggerisce alcune ottimizzazioni comuni di query e schemi che puoi apportare per migliorare il rendimento della replica.

Query a lunga esecuzione nella replica di lettura

Le query che richiedono molto tempo nella replica potrebbero bloccare la replica per Cloud SQL. Potresti voler avere repliche separate per l'elaborazione delle transazioni online (OLTP) e l'elaborazione analitica online (OLAP) e inviare solo query di lunga durata alla replica OLAP.

Blocchi esclusivi a causa di DDL

I comandi DDL (Data Definition Language), come ALTER TABLE e CREATE INDEX, possono causare un ritardo nella replica a causa di bloccati esclusivi. Per evitare conflitti di blocco, valuta la possibilità di pianificare l'esecuzione di DDL durante i periodi in cui il carico delle query sulle repliche è inferiore.

Inoltre, le istruzioni DDL come CREATE INDEX, ALTER INDEX e INDEX MAINTENANCE possono causare un ritardo nella replica a causa del numero elevato di record del log delle transazioni che queste istruzioni possono generare.

Replica sovraccaricata

Se una replica di lettura riceve troppe query, la replica potrebbe essere bloccata. Valuta la possibilità di suddividere le letture tra più repliche per ridurre il carico su ciascuna.

Per evitare picchi di query, ti consigliamo di limitare le query di lettura della replica nella logica dell'applicazione o in un livello proxy, se ne utilizzi uno.

Se si verificano picchi di attività nell'istanza principale, valuta la possibilità di suddividere gli aggiornamenti.

Database principale monolitico

Valuta la possibilità di eseguire lo sharding del database principale in verticale (o orizzontalmente) per evitare che una o più tabelle in ritardo rallentino tutte le altre.

Monitorare il ritardo della replica

Puoi utilizzare le metriche replica_lag e network_lag per monitorare il ritardo della replica e identificare se la causa del ritardo si trova nel database principale, nella rete o nella replica.

Metrica	Descrizione
Ritardo della replica (cloudsql.googleapis.com/database/replication/seconds_behind_master)	Il numero di secondi in cui lo stato della replica è in ritardo rispetto allo stato dell'istanza principale. Si tratta della differenza tra il timestamp dell'ultimo record del log rielaborato sul secondario e il timestamp dell'ultimo record del log inviato sul principale.
Ritardo della rete (cloudsql.googleapis.com/database/replication/network_lag)	La differenza tra il timestamp dell'ultima voce di log ricevuta sulla replica e l'ultima voce di log inviata sulla principale.

Verifica la replica

Per verificare il funzionamento della replica, controlla il valore della metrica cloudsql.googleapis.com/database/replication/state nell'istanza principale. Se lo stato è Running, la replica è integra.