L'alta affidabilità (HA) in AlloyDB per PostgreSQL mantiene il database operativo e i dati accessibili alle applicazioni client durante gli errori delle zone o delle istanze. A differenza delle istanze di zona, che possono subire tempi di inattività prolungati durante un'interruzione, le istanze ad alta affidabilità eseguono automaticamente il failover tra i nodi attivi e in standby nelle zone. Per configurare un'istanza per l'alta affidabilità, consulta Visualizza le impostazioni dei cluster e delle istanze.
Istanze principali e secondarie
Un'istanza AlloyDB principale configurata con l'alta affidabilità include un nodo attivo e un nodo in standby, che si trovano in zone diverse. Per l'archiviazione, AlloyDB utilizza un sistema di persistenza dei log a livello di regione per archiviare i log write-ahead (WAL) del database e il servizio di archiviazione a livello di regione di AlloyDB per archiviare i blocchi di dati. L'indirizzo IP dell'istanza instrada il traffico al nodo attivo utilizzando un bilanciatore del carico.
Durante l'elaborazione delle scritture, il database AlloyDB scrive prima il WAL nel suo persister dei log regionale sul nodo attivo, quindi trasferisce in modo asincrono i log ai server di elaborazione dei log regionali in AlloyDB, che materializzano i log in blocchi di dati per l'archiviazione a lungo termine. AlloyDB esegue quindi la pulizia dei log elaborati correttamente.
Il seguente diagramma mostra l'architettura ad alta affidabilità.
Fig. 1. Architettura ad alta affidabilità.
Failover
Se il nodo attivo non è disponibile, AlloyDB esegue automaticamente il failover dell'istanza principale sul nodo in standby, che diventa il nuovo nodo attivo. Il bilanciatore del carico riconosce il nuovo nodo attivo e inizia a instradare il traffico verso questo nodo. Dopo un failover, il nuovo nodo attivo rimane attivo anche dopo che il nodo originale torna online. Durante il failover non si verifica alcuna perdita di dati grazie alle scritture WAL sincrone nel sistema di persistenza dei log a livello di regione.
Il seguente diagramma mostra il flusso di traffico dopo il failover.
Fig. 2. Flusso di traffico dopo il failover.
Un failover si verifica nella seguente sequenza di eventi:
- Il nodo o la zona attiva non funziona. Il sistema di monitoraggio dell'integrità di AlloyDB controlla periodicamente se il nodo attivo è integro. Se il sistema di monitoraggio dell'integrità non supera più controlli, avvia il failover. Questo rilevamento può richiedere fino a 30 secondi.
- Il database viene avviato sul nodo in standby e inizia ad accettare le connessioni. In genere, questa operazione richiede meno di 30 secondi.
- Il nodo di riserva viene promosso a principale. Utilizzando l'indirizzo IP statico dell'istanza, il nuovo nodo primario inizia a fornire i dati e le query del client vengono eseguite correttamente dopo una riconnessione.
- AlloyDB ricrea un nodo standby nella zona precedentemente attiva. Questo nodo in standby è quindi pronto per i futuri failover.
Requisiti
Affinché AlloyDB consenta il failover, la configurazione deve soddisfare questi requisiti:
- L'istanza principale deve essere in uno stato operativo normale (non arrestata o in manutenzione).
- Sia la zona di standby che il nodo di standby devono essere integri.
Architettura hot standby
Le istanze AlloyDB con PostgreSQL 18 offrono un failover migliorato utilizzando la funzionalità di hot standby.
Con la funzionalità di hot standby, AlloyDB esegue il nodo in standby come replica. Durante il failover, questa replica può passare più rapidamente a una modalità di lettura/scrittura, riducendo i tempi di inattività. Inoltre, la replica consente di utilizzare cache calde, il che contribuisce a garantire prestazioni delle query coerenti dopo il failover.
Il seguente diagramma mostra l'architettura ad alta affidabilità con l'hot standby incluso.
Fig. 3. Hot standby.
Pool di lettura
Le istanze del pool di lettura con due o più nodi sono ad alta affidabilità. I nodi sono distribuiti in modo uniforme tra le zone, creando resilienza agli eventi di errore. In caso di eventi di errore, ad esempio un errore di un nodo o di una zona, un bilanciatore del carico regionale instrada il traffico ai nodi integri rimanenti, garantendo l'assenza di tempi di inattività per i client.
I pool di lettura rimangono online durante un failover dell'istanza principale. La replica WAL dall'istanza principale viene messa in pausa temporaneamente durante il failover e riprende automaticamente dopo il recupero dell'istanza principale.