Questa pagina è stata tradotta dall'API Cloud Translation.

Ritardo della replica

MySQL | PostgreSQL | SQL Server

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 i log WAL al ricevitore WAL nella replica, dove vengono applicati.

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

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

I primi due motivi sopra indicati possono essere monitorati con la metrica network_lag. Il terzo viene osservato tramite la metrica replica_lag. Un valore replica_lag elevato 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 contiene etichette per indicare ulteriori dettagli. Queste metriche sono descritte nella sezione Monitorare il ritardo nella replica di seguito.

Ottimizzare le query e lo schema

Questa sezione suggerisce alcune ottimizzazioni comuni di query e schemi che puoi apportare per migliorare il rendimento della 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 durata 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 delle query non è accettabile, valuta la possibilità di impostare il flag hot_standby_feedback nella replica.

Per ulteriori informazioni, consulta la documentazione di PostgreSQL Hot Standby.

Blocchi esclusivi a causa di 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 conflitti di blocco, valuta la possibilità di pianificare l'esecuzione di DDL durante i periodi in cui il carico delle query sulle repliche è inferiore.

Per ulteriori informazioni, consulta la documentazione di PostgreSQL Hot Standby.

Replica sovraccaricata

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, ti consigliamo 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 suddividere gli 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.

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

Metrica Descrizione

Metrica	Descrizione
Ritardo della replica (`cloudsql.googleapis.com/database/replication/replica_lag`)	Il numero di secondi in cui lo stato della replica è in ritardo rispetto allo stato 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 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 `now() - pg_last_xact_replay_timestamp()` nella replica. Si tratta di un'approssimazione. Se la replica è interrotta, la replica non sa quanto è avanti il database principale e questa metrica non indica il ritardo totale.
Byte di ritardo (`cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag`)	La quantità di byte in base alla quale lo stato della replica è in ritardo rispetto allo stato del database principale. `replica_byte_lag` esporta 4 serie temporali e l'etichetta `replica_lag_type` può indicare uno dei seguenti valori: sent_location: indica quanti byte di WAL sono stati generati, ma non sono ancora stati inviati alla replica. write_location: il ritardo di scrittura meno inviato mostra i byte WAL nella rete che sono stati inviati, ma non ancora scritti nella replica. flush_location: lo svuotamento meno il ritardo di scrittura mostra i byte WAL scritti nella replica, ma non ancora svuotati. replay_location: mostra il ritardo totale in byte. La Riproduzione meno il ritardo di aggiornamento indica il ritardo di riproduzione.
Ritardo della rete (`cloudsql.googleapis.com/database/replication/network_lag`)	Il tempo in secondi necessario dal commit nel database primario per raggiungere il ricevitore WAL nella replica. Se `network_lag` è pari a zero o è trascurabile, ma `replica_lag` è elevato, significa che il ricevitore WAL non è in grado di applicare le modifiche di replica abbastanza velocemente.

Ritardo della replica
(cloudsql.googleapis.com/database/replication/replica_lag)

Il numero di secondi in cui lo stato della replica è in ritardo rispetto allo stato 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 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 now() - pg_last_xact_replay_timestamp() nella replica. Si tratta di un'approssimazione. Se la replica è interrotta, la replica non sa quanto è avanti il database principale e questa metrica non indica il ritardo totale.

Byte di ritardo
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

La quantità di byte in base alla quale lo stato della replica è in ritardo rispetto allo stato del database principale. replica_byte_lag esporta 4 serie temporali e l'etichetta replica_lag_type può indicare uno dei seguenti valori:

sent_location: indica quanti byte di WAL sono stati generati, ma non sono ancora stati inviati alla replica.
write_location: il ritardo di scrittura meno inviato mostra i byte WAL nella rete che sono stati inviati, ma non ancora scritti nella replica.
flush_location: lo svuotamento meno il ritardo di scrittura mostra i byte WAL scritti nella replica, ma non ancora svuotati.
replay_location: mostra il ritardo totale in byte. La Riproduzione meno il ritardo di aggiornamento indica il ritardo di riproduzione.

Ritardo della rete
(cloudsql.googleapis.com/database/replication/network_lag)

Il tempo in secondi necessario dal commit nel database primario per raggiungere il ricevitore WAL nella replica.

Se network_lag è pari a zero o è trascurabile, ma replica_lag è elevato, significa che il ricevitore WAL non è in grado di applicare le modifiche di replica abbastanza velocemente.

Verifica la replica

Per verificare che la replica funzioni, esegui la seguente 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 recente di 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 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)