Risolvere i problemi di replica

AlloyDB ha un'architettura che separa computing e 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 scritture vengono eseguite sull'istanza principale e poi registrate nel Write-Ahead Log (WAL). Queste modifiche vengono poi replicate nei nodi del pool di lettura. Comprendere i due passaggi principali di questo processo di replica è fondamentale per risolvere eventuali problemi:

• Flush WAL: il log write-ahead (WAL), che contiene le modifiche al database, viene inviato dalla replica principale alla replica. La replica rende immediatamente permanente il WAL sul disco.
• Applicazione (o riproduzione) del WAL: il WAL persistente viene riprodotto sulla replica, il che significa che le modifiche vengono applicate alle cache della replica.

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 seguenti due componenti:

• Ritardo di flush o di rete: si tratta del ritardo nella fase di flush del WAL. È il tempo necessario per l'invio del WAL dall'istanza principale e la sua persistenza nella replica.
• Ritardo di riproduzione: si tratta del ritardo nel passaggio di applicazione del WAL. È il tempo necessario alla replica per applicare le modifiche dal WAL.

La scelta di prestare maggiore attenzione al ritardo di flush o al ritardo di replay dipende dal caso d'uso:

• Se ti preoccupa la perdita di dati, ad esempio con i cluster secondari, devi prestare molta attenzione al ritardo di flush. 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 sia al ritardo di flush sia al ritardo di replay. Un ritardo in uno dei due passaggi, ovvero nella trasmissione del WAL o nella sua applicazione, comporta dati inattivi nelle repliche di lettura.

Controlla il ritardo della replica

Puoi monitorare il ritardo di replica delle istanze del pool di lettura nella console Google Cloud . Per saperne di più, consulta Monitora le istanze. Puoi anche monitorare il ritardo di replica del pool di lettura e ricevere avvisi in corrispondenza di 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.

Concorrenza per le risorse

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

• Pressione su CPU e memoria: un workload di lettura intenso 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 utilizzata delle tue istanze nella console Google Cloud . Se l'utilizzo delle risorse è elevato, potrebbe essere necessario fare lo scale up o lo scale out delle 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 alle repliche più risorse.

Conflitti di replica

A volte le query di lettura possono bloccare il processo di replica perché trattengono le risorse che il processo di replica sta aspettando. Se una query di lettura blocca un oggetto del database che il processo di riproduzione deve aggiornare, si verifica un conflitto di blocco. Se una query blocca un buffer di dati che la riproduzione deve modificare, si verifica un conflitto di blocco del buffer. In entrambi i casi, la riproduzione viene bloccata finché la query non rilascia la risorsa.

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

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

• Riduci max_standby_streaming_delay: questo parametro determina il tempo di attesa del processo di riproduzione 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 comportare l'annullamento di un numero maggiore di query di lettura. Puoi ottimizzare questo parametro per trovare il miglior equilibrio per la tua applicazione.

• Evita query a lunga esecuzione: le query a lunga esecuzione sui pool di lettura possono aumentare la probabilità di conflitti di replica. Valuta la possibilità di spostare le query a lunga esecuzione in un pool di lettura diverso in cui un ritardo di replica ridotto non è così fondamentale.

• Verifica che alloydb.promote_cancel_to_terminate sia attivo: questo flag, attivo per impostazione predefinita, consente ad AlloyDB di terminare forzatamente i backend delle query che non rispondono alle richieste di annullamento. In questo modo, i backend che non rispondono non bloccano la replica per periodi prolungati.

Limitazione delle query di lettura basata sul ritardo

AlloyDB ti consente anche di controllare se attivare la limitazione basata sul ritardo delle 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à offre un compromesso che migliora il ritardo di replica fornendo alla riproduzione più risorse per recuperare più velocemente, al costo di un potenziale aumento della latenza delle query 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 sono in ritardo a causa del ritardo della 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 il 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, consulta Monitora le query attive.

Workload elevato

Un aumento improvviso del workload di scrittura sull'istanza principale 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 .

Volume elevato di Write-Ahead-Log a causa della creazione dell'indice ScaNN

La creazione dell'indice ScaNN potrebbe generare grandi quantità di record WAL di scrittura di pagine intere. Ciò può causare un ritardo nell'invio dei record WAL dall'istanza principale alle istanze di lettura. Se il ritardo di replica corrisponde alla creazione dell'indice ScaNN su un numero elevato di embedding, puoi attivare wal_compression sull'istanza principale per risparmiare I/O di rete e disco e ridurre il ritardo di replica. Ciò potrebbe comportare un piccolo overhead aggiuntivo della CPU.

wal_compression comprime solo i record di scrittura di pagine intere e non ha effetto sulla maggior parte dei record WAL. La modifica di questo flag non richiede il riavvio e non comporta tempi di inattività.

Transazioni di grande entità

Le transazioni che modificano un numero elevato di righe, ad esempio eliminando più tabelle o tabelle di grandi dimensioni, generano record COMMIT o ABORT eccezionalmente grandi nel Write-Ahead Log (WAL). La riproduzione di questi record sui nodi del pool di lettura può richiedere molto tempo, con un conseguente aumento temporaneo del ritardo di replica.

Per mitigare questo problema, evita di eseguire operazioni batch di grandi dimensioni, come le eliminazioni, in una singola transazione. Suddividi invece queste operazioni in transazioni più piccole e frequenti. In questo modo, le dimensioni dei singoli record COMMIT e ABORT vengono ridotte, consentendo al flusso di replica di rimanere più fluido e riducendo il ritardo di replica di picco.

Risolvi i problemi che impediscono la replica

Per avere un ritardo di replica, devi avere 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.

Arresti anomali dell'istanza del pool di lettura

In PostgreSQL 14, una transazione di lunga durata sull'istanza principale che contiene un lungo elenco di blocchi esclusivi potrebbe causare l'aumento della memoria utilizzata di una replica di lettura, il che potrebbe portare all'arresto anomalo dell'istanza del pool di lettura.

Per mitigare questo problema, puoi terminare la transazione a lunga esecuzione nell'istanza principale.

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à della replica di riprodurre i dati dipende dal carico che ha. Se aggiorni la configurazione dell'istanza, ad esempio ridimensionandola, a seconda del workload, la replica potrebbe non avere una cache completamente preriscaldata al termine dell'operazione. Ciò significa che la riproduzione o l'elaborazione dei record non ancora memorizzati nella cache è più lenta. In questo caso, il ritardo di riproduzione potrebbe aumentare temporaneamente.