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 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 in cui 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 riesce a inviare le modifiche alla replica abbastanza velocemente.
- La replica non riesce a ricevere le modifiche abbastanza rapidamente.
- La replica non riesce ad applicare le modifiche abbastanza rapidamente.
network_lag
metric. Il terzo motivo viene osservato tramite la metrica seconds_behind_master. Un valore
elevato della metrica seconds_behind_master indica che la replica non riesce ad applicare
le modifiche alla replica abbastanza rapidamente. Queste metriche sono descritte nella sezione
Monitorare il ritardo di replica di seguito.
Ottimizzare query e 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 esecuzione prolungata 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 esecuzione prolungata alla replica OLAP.
Blocchi esclusivi dovuti al DDL
I comandi Data Definition Language (DDL), come ALTER TABLE e
CREATE INDEX, possono causare un ritardo della replica nella replica a causa di
blocchi esclusivi. Per evitare conflitti di blocco, valuta la possibilità di pianificare l'esecuzione di DDL
durante i periodi in cui il carico di query è inferiore sulle repliche.
CREATE INDEX, ALTER INDEX e INDEX
MAINTENANCE possono causare un ritardo della replica a causa del numero elevato di record di 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 dividere 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 delle repliche 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 primario monolitico
Valuta la possibilità di partizionare verticalmente (o orizzontalmente) il database principale per evitare 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 di replica e identificare se la causa del ritardo si trova nel database primario, nella rete o nella replica.
| Metrica | Descrizione |
|---|---|
| Ritardo della replica ( cloudsql.googleapis.com/database/replication/seconds_behind_master) |
Il numero di secondi di ritardo dello stato della replica rispetto allo stato dell'istanza principale. Questa è la differenza tra il timestamp dell'ultimo record di log rifatto sul secondario e il timestamp dell'ultimo record di log inviato sul primario. |
| Ritardo di rete ( cloudsql.googleapis.com) |
La differenza tra il timestamp dell'ultima voce di log ricevuta sulla replica e l'ultima voce di log inviata sul database primario. |
Verifica la replica
Per verificare che la replica funzioni, controlla il valore della metricacloudsql.googleapis.com/database/replication/state nell'istanza
principale. Se lo stato è Running, la replica è integra.