Risolvere i problemi di replica

AlloyDB ha un'architettura che separa il computing e l'archiviazione, consentendo a ciascuno di scalare in modo indipendente. Anche se le istanze principali e del pool di lettura condividono 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). Queste modifiche vengono quindi 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 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.
• 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 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 i cluster secondari, devi prestare molta attenzione al ritardo di scaricamento. 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 scaricamento che al ritardo di riproduzione. Un ritardo in uno dei passaggi, sia nella trasmissione del WAL sia nella sua applicazione, comporta dati obsoleti nelle repliche di lettura.

Controllare 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 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 scalare orizzontalmente 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. Se una query di lettura mantiene un blocco su un oggetto di database che il processo di riproduzione deve aggiornare, si verifica un conflitto di blocco. Se una query contiene un blocco su 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 ridurre i conflitti di replica, puoi procedere nel seguente modo:

• Reduce max_standby_streaming_delay: questo parametro determina per quanto tempo il processo di riproduzione attende prima di annullare le query che lo bloccano. Il valore predefinito è 30 secondi. Ridurre 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.

• 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. Ciò può contribuire a impedire che i backend che non rispondono blocchino 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 di 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 il replay per recuperare più rapidamente, a costo di aumentare potenzialmente la 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 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 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, 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 primaria nella console Google Cloud .

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 nei nodi del pool di lettura può richiedere molto tempo, con conseguente aumento temporaneo del ritardo della replica.

Per risolvere questo problema, evita di eseguire operazioni batch molto grandi, come le eliminazioni, in un'unica transazione. Suddividi invece queste operazioni in transazioni più piccole e frequenti. In questo modo si riducono le dimensioni dei singoli record COMMIT e ABORT, consentendo al flusso di replica di rimanere più fluido e riducendo il ritardo di replica di picco.

Risolvere i problemi che impediscono la replica

Prima di poter 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 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 portare all'arresto anomalo dell'istanza del pool di lettura.

Per risolvere questo 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à della replica di riprodurre 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 nella riproduzione potrebbe aumentare temporaneamente.