Risolvere i problemi di replica

AlloyDB ha un'architettura che separa il computing e l'archiviazione, consentendo a ciascuno di scalare in modo indipendente. Sebbene le istanze principali e del pool di lettura condividano lo stesso spazio di archiviazione sottostante, la replica è comunque un processo fondamentale per mantenere la coerenza e l'aggiornamento dei dati nelle repliche di lettura. In un cluster AlloyDB, le operazioni di scrittura vengono eseguite sull'istanza principale e poi registrate nel log Write-Ahead (WAL) sullo spazio di archiviazione condiviso. Queste modifiche vengono quindi replicate nelle cache in memoria delle istanze del pool di lettura. Comprendere i due passaggi principali di questo processo di replica è fondamentale per risolvere eventuali problemi:

  • Flush WAL: il Write-Ahead Log (WAL), che contiene le modifiche al database, viene inviato dal database principale alla replica. La replica rende immediatamente permanente il WAL sul disco. I ritardi in uno di questi passaggi contribuiscono a quello che è noto come ritardo di replica. Tuttavia, questo termine potrebbe essere ambiguo. Per essere più precisi, possiamo suddividere il ritardo di replica nei due componenti seguenti:

  • Flush o ritardo di rete: questo è il ritardo nel passaggio di flush del WAL. È il tempo necessario per l'invio del WAL dalla replica principale e la sua persistenza sulla replica.

  • Ritardo di riproduzione: questo è il ritardo nel passaggio di applicazione di WAL. È il tempo necessario alla replica per applicare le modifiche dal WAL.

Se devi preoccuparti di più del ritardo di scaricamento o di riproduzione dipende dal tuo caso d'uso:

  • Se ti preoccupa la perdita di dati, ad esempio con le repliche tra regioni, devi prestare molta attenzione al ritardo di svuotamento. Se il WAL non è ancora persistente sulla replica e l'istanza principale si arresta in modo anomalo, le modifiche vengono perse dal punto di vista della replica.
  • Se ti preoccupa l'aggiornamento dei dati sulle repliche di lettura, devi prestare molta attenzione al ritardo di riproduzione. Un ritardo di replica elevato significa che i dati sulle repliche di lettura non sono aggiornati.

Controllare il ritardo della replica

Puoi monitorare il ritardo di replica delle istanze di pool di lettura nella console Google Cloud . Per saperne di più, vedi Monitorare le istanze. Puoi anche monitorare il ritardo di replica del pool di lettura e ricevere avvisi a una soglia specificata utilizzando Crea policy di avviso basate su soglie metriche.

Cause comuni del ritardo della replica

Di seguito sono riportate alcune cause comuni del ritardo di replica e come risolverle.

Contesa delle risorse

La replica potrebbe anche essere rallentata dalla contesa per le risorse di sistema, come CPU e memoria.

  • Pressione di CPU e memoria: un carico di lavoro di lettura elevato su un'istanza del pool di lettura può competere con il processo di replica per le risorse di CPU e memoria. Puoi controllare l'utilizzo di CPU e memoria delle tue istanze nella console Google Cloud . Se noti un utilizzo elevato delle risorse, potresti dover aumentare o fare lo scale out le istanze del pool di lettura.
  • Dimensioni dei nodi del pool di lettura: se l'istanza principale è molto più grande dei nodi del pool di lettura, potrebbe generare log di replica più velocemente di quanto i nodi di lettura possano elaborarli. In questi casi, è consigliabile utilizzare nodi di lettura di dimensioni maggiori per fornire più risorse alle repliche.

Conflitti di replica

A volte le query di lettura possono bloccare il processo di replica perché mantengono le risorse che il processo di replica sta aspettando. Ad esempio, se una query di lettura ha un blocco su un oggetto di database che il processo di replica deve aggiornare, la replica viene bloccata finché il blocco non viene rilasciato. Questi sono noti come conflitti di buffer pin.

Puoi identificare questi conflitti cercando i messaggi canceling statement due to conflict with recovery nel file postgres.log in Esplora log.

Per ridurre i conflitti di replica, puoi procedere nel seguente modo:

  • Reduce max_standby_streaming_delay: questo parametro determina per quanto tempo il processo di replica attende prima di annullare le query che lo bloccano. Il valore predefinito è 30 secondi. La riduzione di questo valore può contribuire a ridurre il ritardo di replica, ma potrebbe anche causare l'annullamento di un maggior numero di query di lettura. Puoi ottimizzare questo parametro per trovare il miglior equilibrio per la tua applicazione.

  • Evita query a esecuzione prolungata: le query a esecuzione prolungata sui pool di lettura possono aumentare la probabilità di conflitti di replica. Valuta la possibilità di spostare le query a esecuzione prolungata in un altro pool di lettura in cui il ritardo di replica basso non è così critico.

  • Attiva alloydb.promote_cancel_to_terminate: questo flag, attivo per impostazione predefinita, consente ad AlloyDB di terminare forzatamente i backend delle query che non rispondono alle richieste di annullamento. Ciò può contribuire a impedire che i backend che non rispondono blocchino la replica per periodi prolungati.

Limitazione temporanea delle query di lettura

AlloyDB ti consente anche di controllare se attivare la limitazione basata sul ritardo di una query di lettura sui nodi di lettura utilizzando il flag google_storage.log_replay_throttle_read_transactions. Se il parametro è impostato sul valore predefinito on, le query di lettura vengono limitate mettendo in pausa l'avvio di nuove query e la lettura di nuovi buffer per un massimo di un minuto quando il ritardo di replica supera un secondo. Questa funzionalità fa un compromesso che migliora il ritardo di replica fornendo più risorse per la riproduzione per recuperare più rapidamente, a costo di aumentare potenzialmente la latenza di lettura. Se la tua applicazione non è sensibile al ritardo di replica, puoi dare la priorità al miglioramento della latenza delle query di lettura impostando google_storage.log_replay_throttle_read_transactions su off.

Puoi monitorare l'impatto della limitazione delle query utilizzando i seguenti metodi:

  • Log: cerca i messaggi Delayed.*due to replica lag nel file postgres.log in Esplora log per identificare quando le query vengono ritardate a causa del ritardo di replica.

  • Cloud Monitoring: utilizza la metrica alloydb.googleapis.com/instance/postgresql/wait_count per vedere quante query sono state limitate. Per farlo, filtra la metrica in base a wait_event_name e cerca HighLagThrottle. Per visualizzare il tempo totale di limitazione delle query, puoi utilizzare la metrica alloydb.googleapis.com/instance/postgresql/wait_time con lo stesso filtro. Per saperne di più, consulta Riferimento alle metriche di System Insights.

  • Query Insights: nella dashboard Query Insights, la visualizzazione Query attive mostra l'evento di attesa HighLagThrottle nella colonna Evento di attesa quando una query viene limitata a causa del ritardo di replica. Per maggiori dettagli, vedi Monitorare le query attive.

Carico di lavoro elevato

Un aumento improvviso del workload di scrittura sull'istanza primaria può generare una grande quantità di log di replica, che possono sovraccaricare le istanze del pool di lettura e causare un ritardo della replica. Puoi monitorare il traffico di scrittura sull'istanza principale nella console Google Cloud .

Transazioni di grande entità

Le transazioni di grandi dimensioni, come i record COMMIT o ABORT che interessano un numero elevato di righe, possono richiedere molto tempo per essere replicate nelle istanze del pool di lettura. In PostgreSQL 14, una transazione a esecuzione prolungata che contiene un lungo elenco di blocchi esclusivi potrebbe causare un aumento dell'utilizzo della memoria della replica di lettura, il che potrebbe alla fine portare all'arresto anomalo dell'istanza del pool di lettura.

Per risolvere il problema, puoi terminare la transazione a lunga esecuzione sull'istanza primaria.

Risolvere i problemi che impediscono la replica

Prima di poter avere un ritardo di replica, devi disporre di un pool di lettura funzionante. I seguenti problemi potrebbero impedire del tutto la replica, impedendo la creazione di un pool di lettura o causando l'arresto anomalo di una replica di lettura.

Problemi di creazione del pool di lettura

Se la creazione di un pool di lettura non riesce, potresti visualizzare un messaggio Failed to create read pool nei log di AlloyDB su Cloud Logging. Ciò potrebbe accadere se il cluster ha raggiunto il limite massimo di spazio di archiviazione, impedendo all'istanza primaria di allocare altro spazio. Anche se AlloyDB scala automaticamente lo spazio di archiviazione, potrebbe essere necessario esaminare cosa consuma spazio di archiviazione ed eliminare i dati non necessari oppure contattare l'assistenza per richiedere un aumento della quota di spazio di archiviazione.

Arresti anomali dell'istanza del pool di lettura

In PostgreSQL 14, una transazione a esecuzione prolungata sull'istanza principale che contiene un lungo elenco di blocchi esclusivi potrebbe causare un aumento dell'utilizzo della memoria di una replica di lettura, il che potrebbe alla fine causare l'arresto anomalo dell'istanza del pool di lettura.

Per risolvere il problema, puoi terminare la transazione a lunga esecuzione sull'istanza primaria.

Impatto del ridimensionamento dell'istanza sul ritardo della replica

L'architettura di archiviazione di AlloyDB garantisce che il ritardo di svuotamento del pool di lettura non sia influenzato dal ridimensionamento dell'istanza. Tuttavia, lo stesso non vale per la replica. La capacità di riproduzione della replica dipende dal carico. Se aggiorni la configurazione dell'istanza, ad esempio ridimensionandola, a seconda del carico di lavoro, la replica potrebbe non avere una cache completamente precaricata al termine dell'operazione. Ciò significa che la riproduzione o l'elaborazione dei record che non sono ancora stati memorizzati nella cache è più lenta. In questo caso, il ritardo della riproduzione potrebbe aumentare temporaneamente.