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 la replica dei flussi di dati PostgreSQL. Le modifiche vengono scritte nel log Write-Ahead (WAL) nell'istanza principale. Il mittente WAL invia il token WAL al destinatario 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 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 la metrica network_lag. Il terzo viene osservato tramite la metrica replica_lag. Un valore replica_lag elevato indica che la replica non può applicare modifiche alla replica abbastanza velocemente. Il tempo totale può essere osservato tramite la metrica replica_byte_lag, con etichette per indicare ulteriori dettagli. 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.

Valuta la possibilità di modificare i flag max_standby_archive_delay e max_standby_streaming_delay per la replica.

Se sospetti che la causa del problema sia VACUUM e l'annullamento della query non sia 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 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.

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

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

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 attuale 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 quest'ultima 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 viene 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 con cui lo stato della replica è in ritardo rispetto allo stato del database primario. `replica_byte_lag` esporta quattro serie temporali. L'etichetta `replica_lag_type` può indicare uno dei seguenti elementi: sent_location::indica il numero di byte di WAL generati, ma non ancora inviati alla replica. write_location::il valore di scrittura meno il ritardo inviato mostra i byte WAL nella rete che sono stati inviati ma non ancora scritti nella replica. flush_location: il valore Flush meno il tempo di scrittura mostra i byte WAL scritti nella replica, ma non ancora svuotati nella replica. replay_location: mostra il ritardo totale in byte. Il ritardo di ripetizione della riproduzione meno il tempo di svuotamento indica il ritardo di ripetizione.
Tempo di rete (`cloudsql.googleapis.com/database/replication/network_lag`)	La quantità di tempo in secondi che occorre dal commit nel database principale per raggiungere il ricevitore WAL nella replica. Se il valore `network_lag` è zero o trascurabile, ma il valore `replica_lag` è elevato, significa che il ricevitore WAL non è in grado di applicare le modifiche alla 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 attuale 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 quest'ultima 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 viene 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 con cui lo stato della replica è in ritardo rispetto allo stato del database primario. replica_byte_lag esporta quattro serie temporali. L'etichetta replica_lag_type può indicare uno dei seguenti elementi:

sent_location::indica il numero di byte di WAL generati, ma non ancora inviati alla replica.
write_location::il valore di scrittura meno il ritardo inviato mostra i byte WAL nella rete che sono stati inviati ma non ancora scritti nella replica.
flush_location: il valore Flush meno il tempo di scrittura mostra i byte WAL scritti nella replica, ma non ancora svuotati nella replica.
replay_location: mostra il ritardo totale in byte. Il ritardo di ripetizione della riproduzione meno il tempo di svuotamento indica il ritardo di ripetizione.

Tempo di rete
(cloudsql.googleapis.com/database/replication/network_lag)

La quantità di tempo in secondi che occorre dal commit nel database principale per raggiungere il ricevitore WAL nella replica.

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

Verifica replica

Per verificare che la replica funzioni, esegui la seguente istruzione sulla replica:

select status, last_msg_receipt_time from pg_stat_wal_receiver;

In caso di replica, vedrai lo stato streaming e un report 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)