Ritardo della replica

MySQL   |  PostgreSQL   |  SQL Server

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

Panoramica

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

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

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

I primi due scenari elencati possono essere monitorati con la network_lag metric. Per saperne di più sulla metrica, consulta Monitorare il ritardo della replica.

Assicurarsi che la replica sia sottoposta a provisioning adeguato

Un'istanza di replica più piccola dell'istanza principale (ad esempio, con meno vCPU e memoria) può subire un ritardo della replica. Una replica più piccola potrebbe anche avere flag di configurazione predefinita diversi rispetto a un'istanza principale più grande. Ti consigliamo di fare in modo che l'istanza di replica sia almeno grande quanto l'istanza principale per avere risorse sufficienti a gestire il carico di replica.

Anche un utilizzo elevato della CPU sulla replica può causare un ritardo della replica. Se l'utilizzo della CPU della replica è elevato (ad esempio, superiore al 90%), valuta la possibilità di aumentare la capacità della CPU della replica.

Ottimizzare le query e lo schema

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

Query a lunga esecuzione nella replica di lettura

Le query a lunga esecuzione 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 a lunga esecuzione alla replica OLAP.

Blocchi esclusivi dovuti a DDL

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

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

Replica sovraccarica

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, valuta la possibilità 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 distribuire gli aggiornamenti.

Database principale monolitico

Valuta la possibilità di partizionare verticalmente (o orizzontalmente) il database principale per impedire che una o più tabelle in ritardo blocchino tutte le altre tabelle.

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 è nel database principale, nella rete o nella replica.

Metrica	Descrizione
Ritardo della rete (cloudsql.googleapis.com/database/replication/network_lag)	La differenza tra il timestamp dell'ultima voce di log ricevuta nella replica e l'ultima voce di log inviata nell'istanza principale. Poiché network_lag viene arrotondato al secondo più vicino, un valore segnalato di 1 secondo può rappresentare un ritardo sottostante che va da uno o due millisecondi a un secondo intero.

Verificare la replica

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

Qual è il passaggio successivo?

• Promozione di repliche per la migrazione a livello di area geografica o il disaster recovery