Questa pagina descrive come risolvere e correggere il ritardo di replica per le repliche di lettura Cloud SQL.
Panoramica
Le repliche di lettura Cloud SQL utilizzano la replica in 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 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
.
La terza viene osservata tramite la metrica replica_lag
. Un valore elevato di replica_lag
indica che
la replica non riesce ad applicare le modifiche di replica abbastanza rapidamente. Il ritardo totale può essere
osservato tramite la metrica replica_byte_lag
, che ha etichette per indicare ulteriori
dettagli. 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.
Valuta la possibilità di modificare i flag max_standby_archive_delay
e
max_standby_streaming_delay
per la tua replica.
Se sospetti che il problema sia VACUUM e l'annullamento della query non è accettabile,
valuta la possibilità di impostare il flag hot_standby_feedback
nella replica.
Per saperne di più, consulta la documentazione di PostgreSQL.
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.
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
della 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 ) |
Il numero di secondi di ritardo dello stato della replica rispetto allo stato dell'istanza principale. Si tratta della differenza tra l'ora attuale e il timestamp originale in cui il database principale ha eseguito il commit della transazione attualmente in fase di applicazione sulla replica. In particolare, le scritture potrebbero essere conteggiate come in ritardo anche se sono state ricevute dalla replica, se la replica non ha ancora applicato la scrittura al database. Questa metrica viene calcolata utilizzando |
Byte di ritardo ( cloudsql.googleapis.com ) |
La quantità di byte per cui lo stato della replica è in ritardo rispetto allo stato del database principale.
|
Ritardo di rete ( cloudsql.googleapis.com ) |
Il tempo in secondi necessario dal commit nel database primario per raggiungere il ricevitore WAL nella replica. Se |
Verifica la replica
Per verificare che la replica funzioni, esegui questa istruzione sulla replica: select status, last_msg_receipt_time from pg_stat_wal_receiver;
Se la replica è in corso, viene visualizzato lo stato streaming
e un valore
last_msg_receipt_time recente:
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 viene eseguita, viene restituito un risultato vuoto:
postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
status | last_msg_receipt_time
--------+-----------------------
(0 rows)