Ritardo della replica

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 di 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.
I primi due motivi sopra riportati possono essere monitorati con la metrica 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.

Assicurati che la replica sia sottoposta a provisioning adeguato

Un'istanza di replica più piccola dell'istanza principale (ad esempio, con meno vCPU e memoria) può subire un ritardo nella replica. Una replica più piccola potrebbe avere anche flag di configurazione predefiniti diversi rispetto a un'istanza primaria più grande. Ti consigliamo di creare un'istanza di replica almeno delle stesse dimensioni dell'istanza primaria per avere risorse sufficienti a gestire il carico di replica.

Un utilizzo elevato della CPU sulla replica può anche causare un ritardo della replica. Se l'utilizzo della CPU della replica è elevato (ad esempio, superiore al 90%), valuta la possibilità di aumentare la capacità della CPU della replica.

Puoi utilizzare il comando SHOW ALL per visualizzare la configurazione della replica e dell'istanza primaria e confrontarle per individuare le differenze.

Ottimizzare le query e lo 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. Ciò può accadere quando la replica tenta di applicare modifiche (ad esempio da un'operazione VACUUM) a righe lette da una query sulla replica.

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.

Per risolvere i ritardi o i blocchi della replica causati da transazioni di lunga durata, ti consigliamo di procedere come segue:

  • Modifica i flag di ritardo in standby. I flag max_standby_archive_delay e max_standby_streaming_delay controllano per quanto tempo una replica attenderà prima di annullare le query di standby in conflitto con la replica. Valori ragionevoli sono spesso compresi tra 30 e 60 secondi. Puoi controllare la visualizzazione pg_stat_database_conflicts per gli approfondimenti sui conflitti tra query.
  • Attiva il flag hot_standby_feedback. L'impostazione del flag hot_standby_feedback su on nella replica può essere utile ritardando le operazioni di vacuum sull'istanza principale. Tuttavia, questo può causare un aumento delle dimensioni della tabella sul database primario, quindi è un compromesso.

Per saperne di più, consulta la documentazione di PostgreSQL.

Ritardo di rete elevato

Un ritardo elevato della rete indica che i record WAL non vengono inviati dal server primario o ricevuti dalla replica abbastanza velocemente. Le cause potrebbero essere le seguenti:

  • Replica tra regioni. La replica tra regioni diverse può introdurre una latenza di rete più elevata.
  • Utilizzo elevato della CPU principale. Se la CPU del server primario supera il 90%, il processo di invio WAL potrebbe non avere tempo CPU sufficiente. Valuta la possibilità di ridurre il carico sul primario o di aumentare la CPU.
  • Utilizzo elevato della CPU della replica. Se la CPU della replica è superiore al 90%, il il processo di ricezione WAL potrebbe non avere abbastanza tempo di CPU. Valuta la possibilità di ridurre il carico sulla replica o di aumentare la relativa CPU.
  • Problemi di larghezza di banda di rete o colli di bottiglia di I/O del disco. Potrebbe essere utile una regione più vicina o una configurazione del disco con una velocità effettiva più elevata. Valuta la possibilità di modificare il valore del flag wal_compression nell'istanza principale per ridurre il traffico tra regioni.
Puoi monitorare il ritardo di rete con la metrica cloudsql.googleapis.com/database/replication/network_lag. Questa metrica ha un limite massimo di 25 secondi, anche se il ritardo effettivo è superiore.

Questa metrica network_lag è simile alla metrica cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag che misura il ritardo sent_location in termini di byte indicato dall'etichetta replica_lag_type.

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.

Per saperne di più, consulta la documentazione di PostgreSQL.

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.

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

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

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 now() - pg_last_xact_replay_timestamp() nella replica. Si tratta di un'approssimazione. Se la replica è interrotta, la replica non saprà quanto è avanti il database primario e questa metrica non indicherà il ritardo totale.
Byte di ritardo
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

La quantità di byte per cui 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 l'invio mostra i byte WAL nella rete che sono stati inviati ma non ancora scritti nella replica.
  • flush_location: Flush minus write lag mostra i byte WAL scritti nella replica ma non ancora scaricati.
  • replay_location: mostra il ritardo totale in byte. Il ritardo di replay indica il ritardo di riproduzione.
Ritardo di 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 è zero o trascurabile, ma replica_lag è elevato, significa che il destinatario WAL non è in grado di applicare le modifiche di replica abbastanza rapidamente.

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)

Qual è il passaggio successivo?