Ritardo della replica

MySQL   |  PostgreSQL   |  SQL Server

Questa pagina descrive come risolvere il problema del tempo di replica per le repliche di lettura di Cloud SQL.

Panoramica

Le repliche di lettura di Cloud SQL utilizzano i gruppi di disponibilità sempre attivi di SQL Server per la replica. Le modifiche vengono scritte nel log Transaction (Transazione) nell'istanza principale. L'istanza principale inoltra le transazioni a eventuali istanze di replica secondarie, dove vengono applicate le modifiche. La modalità di disponibilità utilizzata è modalità di commit asincrono.

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

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

I primi due motivi di cui sopra 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 di replica di seguito.

Ottimizza query e schema

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

Query a lunga esecuzione nella replica di lettura

Le query a lunga esecuzione nella replica potrebbero bloccare la replica per Cloud SQL. È consigliabile 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 a causa di DDL

I comandi Data Definition Language (DDL), come ALTER TABLE e CREATE INDEX, possono causare un ritardo di replica nella replica a causa di blocchi esclusivi. Per evitare la contesa dei blocchi, ti consigliamo di pianificare l'esecuzione di DDL nei momenti in cui il carico delle query è inferiore sulle repliche.

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

Replica con sovraccarico

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 ognuna.

Per evitare picchi di query, valuta la possibilità di limitare le query di lettura delle repliche nella logica dell'applicazione o in un livello proxy, se ne utilizzi uno.

In caso di picchi di attività sull'istanza principale, valuta la possibilità di distribuire gli aggiornamenti.

Database primario monolitico

Valuta la possibilità di partizionare in orizzontale il database principale in verticale (o orizzontalmente) per evitare che una o più tabelle in ritardo contengano tutte le altre.

Monitora il ritardo della replica

Puoi utilizzare le metriche replica_lag e network_lag per monitorare il ritardo di replica e identificare se la causa del ritardo risiede 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 di log ripetuto sul secondario e il timestamp dell'ultimo record di log inviato nell'istanza principale.
Tempo di 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.

Verifica 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 è integro.