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 la replica streaming PostgreSQL. Le modifiche vengono scritte nel log write-Ahead (WAL) nell'istanza principale. Il mittente WAL invia il WAL al ricevitore WAL nella replica, dove vengono applicati.Il ritardo della replica può verificarsi in alcuni scenari, ad esempio:
- L'istanza principale non può inviare le modifiche alla replica abbastanza velocemente.
- La replica non può ricevere le modifiche abbastanza rapidamente.
- La replica non può applicare le modifiche abbastanza rapidamente.
network_lag
.
Il terzo viene osservato tramite la metrica replica_lag
. replica_lag
alto indica che
la replica non riesce ad applicare
le modifiche alla replica abbastanza velocemente. Il ritardo totale può essere
osservato tramite la metrica replica_byte_lag
, che ha etichette per indicare ulteriormente
i dettagli. Queste metriche sono descritte nella sezione Monitorare il ritardo della replica.
di seguito.
Ottimizza query e schema
Questa sezione suggerisce alcune ottimizzazioni comuni dello schema e delle query che puoi apportare per migliorare le prestazioni di 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 esecuzione alla replica OLAP.
Ti consigliamo di modificare max_standby_archive_delay
e
max_standby_streaming_delay
flag per la tua replica.
Se sospetti che la causa sia VACUUM e l'annullamento della query non sia accettabile,
valuta la possibilità di impostare il flag hot_standby_feedback
nella replica.
Rivedi Documentazione di PostgreSQL Hot Standby per ulteriori informazioni.
Blocchi esclusivi a causa del 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 la contesa del blocco, valuta la possibilità di pianificare l'esecuzione del DDL
nei momenti in cui il carico delle query è più basso sulle repliche.
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 ciascuna uno.
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à sull'istanza principale, valuta la possibilità di estenderli 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.
Monitora il ritardo della replica
Puoi utilizzare le metriche replica_lag
e network_lag
per monitorare la replica
e identificare se la causa del ritardo si trova nel database primario
la rete o la replica.
Metrica | Descrizione |
---|---|
Ritardo della replica ( cloudsql.googleapis.com ) |
Il numero di secondi in cui lo stato della replica è in ritardo rispetto alla replica dell'istanza principale. Si tratta della differenza tra l'ora corrente e il timestamp originale in cui il database principale ha eseguito il commit della transazione attualmente applicata alla replica. In particolare, le scritture potrebbero essere considerate in ritardo anche se ricevuti dalla replica, se quest'ultima non è ancora stata applicata la scrittura sul database. Questa metrica viene calcolata utilizzando |
Byte in ritardo ( cloudsql.googleapis.com ) |
La quantità di byte di ritardo rispetto allo stato della replica rispetto alla replica
del database principale.
|
Ritardo della rete ( cloudsql.googleapis.com ) |
La quantità di tempo in secondi richiesta dal commit nell'istanza principale per raggiungere il ricevitore WAL nella replica. Se |
Verifica replica
Per verificare che la replica funzioni, esegui la seguente istruzione su replica:select status, last_msg_receipt_time from pg_stat_wal_receiver;
Se è in corso la replica, vedrai lo stato streaming
e una
last_msg_receipt_time:
postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
status | last_msg_receipt_time
-----------+-------------------------------
streaming | 2020-01-21 20:19:51.461535+00
(1 row)
Se la replica non è in corso, viene restituito un risultato vuoto:
postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
status | last_msg_receipt_time
--------+-----------------------
(0 rows)