Ritardo della replica

MySQL   |  PostgreSQL   |  SQL Server

Questa pagina descrive come risolvere i problemi e correggere il ritardo della replica per le repliche di lettura di Cloud SQL.

Panoramica

Le repliche di lettura di Cloud SQL utilizzano la replica in streaming di PostgreSQL. Le modifiche vengono scritte nel Write-Ahead Log (WAL) nell'istanza principale. Il mittente WAL invia il WAL al ricevitore WAL nella replica, dove vengono applicate.

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 velocemente.
• La replica non riesce ad applicare le modifiche abbastanza velocemente.

I primi due scenari elencati possono essere monitorati con la metrica network_lag. Il terzo viene osservato utilizzando la metrica replica_lag. Un valore elevato di replica_lag indica che la replica non riesce ad applicare le modifiche di replica abbastanza velocemente. Il ritardo totale può essere osservato utilizzando la metrica replica_byte_lag, che ha etichette per indicare ulteriori dettagli. Per ulteriori informazioni su queste metriche, consulta Monitorare il ritardo della replica.

Assicurarsi che la replica sia adeguatamente sottoposta a provisioning

Un'istanza di replica più piccola dell'istanza principale (ad esempio, con meno vCPU e memoria) può subire un ritardo della replica. Una replica più piccola potrebbe anche avere flag di configurazione predefiniti diversi rispetto a un'istanza principale più grande. Ti consigliamo di fare in modo che l'istanza di replica sia almeno grande quanto l'istanza principale per avere risorse sufficienti a gestire il carico di replica.

Anche un utilizzo elevato della CPU sulla replica può 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 principale 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 lunga esecuzione nella replica potrebbero bloccare la replica per Cloud SQL. Questo può accadere quando la replica tenta di applicare modifiche (ad esempio da un'operazione VACUUM) alle 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 lunga esecuzione alla replica OLAP.

Per risolvere i ritardi o i blocchi della replica causati da transazioni a lunga esecuzione, ti consigliamo di:

• Modificare 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 in standby in conflitto con la replica. I valori ragionevoli sono spesso compresi tra 30 e 60 secondi. Puoi controllare la pg_stat_database_conflicts visualizzazione per informazioni sui conflitti di query.
• Attivare 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 sull'istanza principale, quindi è un compromesso.

Per ulteriori informazioni, consulta la documentazione di PostgreSQL.

Ritardo di rete elevato

Un ritardo di rete elevato indica che i record WAL non vengono inviati dall'istanza principale o ricevuti dalla replica abbastanza velocemente. Questo può essere causato da:

• Replica tra regioni. La replica tra regioni diverse può introdurre una latenza di rete più elevata.
• Utilizzo elevato della CPU principale. Se la CPU principale è superiore al 90%, il processo del mittente WAL potrebbe non avere abbastanza tempo della CPU. Valuta la possibilità di ridurre il carico sull'istanza principale o di aumentarne la CPU.
• Utilizzo elevato della CPU della replica. Se la CPU della replica è superiore al 90%, il processo del ricevitore WAL potrebbe non avere abbastanza tempo della CPU. Valuta la possibilità di ridurre il carico su la replica o di aumentarne la CPU.
• Problemi di larghezza di banda di rete o colli di bottiglia di I/O del disco. Una regione più vicina o una configurazione del disco con una velocità effettiva più elevata potrebbero essere utili. 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 è maggiore.

Nota: poiché network_lag viene arrotondato al secondo più vicino, un valore segnalato di 1 secondo può rappresentare un ritardo sottostante che va da uno o due millisecondi a un secondo intero.

Questa metrica network_lag è simile alla metrica cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag, che misura il ritardo di sent_location in termini di byte indicati dalla relativa etichetta replica_lag_type.

Blocchi esclusivi dovuti a DDL

I comandi DDL (Data Definition Language), come ALTER TABLE e CREATE INDEX, possono causare un ritardo della replica nella replica a causa di blocchi esclusivi. Per evitare la contesa dei blocchi, valuta la possibilità di pianificare l'esecuzione di DDL durante i periodi in cui il carico di query è inferiore sulle repliche.

Per ulteriori informazioni, consulta la documentazione di PostgreSQL.

Replica sovraccarica

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, valuta la possibilità 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à nell'istanza principale, valuta la possibilità di distribuire gli aggiornamenti.

Database principale monolitico

Valuta la possibilità di eseguire lo sharding verticale (o orizzontale) del database principale per impedire 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 è nel database principale, nella rete o nella replica.

Metrica	Descrizione
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 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 saprà quanto è avanti il database principale e questa metrica non indicherà il ritardo totale.
Byte di ritardo (cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)	La quantità di byte di ritardo dello stato della replica rispetto allo stato del database principale. replica_byte_lag esporta 4 serie temporali e l'replica_lag_type etichetta può indicare una delle seguenti: 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 invio mostra i byte WAL nella rete, che sono stati inviati ma non ancora scritti nella replica. flush_location: Il ritardo di scaricamento meno scrittura mostra i byte WAL scritti nella replica ma non ancora scaricati nella replica. replay_location: mostra il ritardo totale in byte. Il ritardo di riproduzione meno scaricamento indica il ritardo di riproduzione.
Ritardo di rete (cloudsql.googleapis.com/database/replication/network_lag)	La quantità di tempo, in secondi, necessaria per raggiungere il ricevitore WAL nella replica dal commit nel database principale. Se il network_lag è zero o trascurabile, ma il replica_lag è elevato, indica che il ricevitore WAL non è in grado di applicare le modifiche di replica abbastanza velocemente. Poiché network_lag viene arrotondato al secondo più vicino, un valore segnalato di 1 secondo può rappresentare un ritardo sottostante che va da uno o due millisecondi a un secondo intero.

Verificare 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, vedrai lo stato streaming e un `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 è 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)

Qual è il passaggio successivo?

• Promozione di repliche per la migrazione a livello di area geografica o il disaster recovery