Comprendere ed eseguire scenari di Failover e Switchover in PostgreSQL

Nelle moderne architetture di database, garantire la continuità operativa tramite l'Alta Disponibilità (HA) è fondamentale. PostgreSQL, un potente database relazionale open-source, si basa sulla replica in streaming per mantenere la coerenza dei dati tra più nodi. Tuttavia, quando il server primario riscontra un problema o richiede manutenzione, gli amministratori di database devono eseguire procedure precise per ripristinare il servizio. Questo articolo differenzia chiaramente due operazioni HA critiche—il Failover e lo Switchover—e descrive in dettaglio i passaggi e le considerazioni per promuovere in sicurezza una replica standby a nuovo primario.

Comprendere la distinzione tra questi eventi è vitale. Uno switchover è una transizione pianificata e controllata, mentre un failover è una risposta di emergenza a un'interruzione imprevista. Gestire con successo entrambi gli scenari dipende fortemente da una configurazione adeguata, un monitoraggio robusto e la familiarità con gli strumenti utilizzati per gestire la replica.

Fondamenti della replica: La base dell'HA

L'Alta Disponibilità di PostgreSQL si basa sulla replica in streaming, dove un server agisce come Primario (o Master) e uno o più server agiscono come Standby (o Repliche). Il Primario trasmette i record del write-ahead log (WAL) agli Standby per mantenerli sincronizzati.

Per gestire efficacemente questi ruoli, sono necessarie impostazioni di configurazione specifiche sia sui nodi primari che su quelli di replica:

Impostazioni di configurazione critiche

Queste impostazioni regolano il funzionamento della replica e il modo in cui i nodi si identificano a vicenda:

• wal_level: Deve essere impostato su replica o superiore (idealmente logical se si utilizzano strumenti che richiedono la decodifica logica) sul Primario.
• max_wal_senders: Definisce il numero massimo di connessioni concorrenti dagli standby. Deve essere aumentato dal valore predefinito (solitamente 10) per accogliere tutti gli standby.
• hot_standby: Deve essere impostato su on nel postgresql.conf del server standby per consentire query di sola lettura durante la replica.
• synchronous_commit: Controlla il riconoscimento delle transazioni. Per la perdita di dati zero durante gli switchover, questo è spesso impostato su on (o remote_write per una tolleranza di latenza minore).
• primary_conninfo: Impostato sullo standby, dettagliando le informazioni di connessione (host, porta, utente, password) per connettersi al Primario corrente.

Buona pratica: Per un'HA robusta, utilizzare strati di connection pooling (come PgBouncer o proxy HA dedicati come Patroni o Repmgr) che astraggono gli indirizzi fisici del server, rendendo failover e switchover trasparenti per le applicazioni.

Switchover: La transizione pianificata

Uno Switchover è un processo controllato e graduale in cui il nodo Primario attivo viene intenzionalmente dismesso e uno Standby designato viene promosso a prendere il suo posto. Questa procedura è tipicamente utilizzata per manutenzione pianificata, aggiornamenti di versione o sostituzioni hardware.

Passaggi per uno Switchover controllato

L'obiettivo di uno switchover è garantire la perdita di dati zero aspettando che tutte le transazioni in corso vengano replicate prima della promozione.

1. Arrestare le scritture sul Primario corrente: Il primo passo è impedire che nuove transazioni vengano commesse sul Primario corrente. Ciò si ottiene spesso impostando default_transaction_read_only = on o chiudendo temporaneamente le connessioni client.
2. Attendere il recupero della replica: Assicurarsi che lo Standby designato abbia ricevuto e applicato tutti i record WAL rimanenti dal Primario. È possibile controllare il ritardo di replica utilizzando pg_stat_replication sul Primario o esaminando lo stato di recupero dello standby.
3. Avviare la promozione dello Standby: Eseguire il comando per promuovere il server Standby scelto al ruolo di Primario. Il comando specifico dipende dallo strumento di gestione utilizzato (ad esempio, pg_ctl promote o un comando del gestore del cluster).
4. Riconfigurare il vecchio Primario: Una volta che lo Standby è stato promosso con successo, il vecchio Primario deve essere riconfigurato per seguire il nuovo Primario come Standby. Ciò comporta l'aggiornamento del suo primary_conninfo.
5. Reindirizzare le applicazioni: Aggiornare il bilanciatore di carico o il connection pooler per dirigere il traffico verso il nuovo server Primario.

Failover: La risposta di emergenza

Il Failover è una procedura immediata e reattiva attivata quando il server Primario corrente fallisce inaspettatamente (ad esempio, crash hardware, partizione di rete, errore software) e non può essere riportato online rapidamente.

Il Failover comporta intrinsecamente un rischio maggiore di perdita di dati perché non vi è alcuna garanzia che le ultime transazioni commesse abbiano avuto il tempo di essere trasmesse agli Standby prima che si verificasse il guasto.

Esecuzione di un Failover di emergenza

Le procedure di Failover sono progettate per velocità e recupero, spesso utilizzando strumenti specializzati per automatizzare la promozione.

1. Determinare lo stato di salute del vecchio Primario: Verificare che il Primario originale sia realmente non disponibile e non stia solo riscontrando un problema di rete transitorio (questo previene pericolosi scenari di 'split-brain').
2. Selezionare il migliore Standby: Scegliere lo Standby con il minor ritardo di replica (quello che è più avanti nel flusso WAL).
3. Promuovere lo Standby: Promuovere immediatamente lo Standby selezionato utilizzando il comando di promozione (pg_ctl promote).
4. Gestire la perdita di dati (se necessario): Se il cluster utilizza la replica asincrona, i dati persi sul Primario fallito potrebbero dover essere riconciliati manualmente o semplicemente accettati, a seconda della tolleranza dell'applicazione.
5. Riconfigurare il Primario precedente: Una volta recuperato il Primario originale, deve essere pulito, reinizializzato (spesso richiedendo un backup di base dal nuovo Primario) e configurato per seguire il nuovo Primario.

Strumenti per una promozione sicura: Repmgr vs. Patroni

Mentre la promozione manuale utilizzando pg_ctl è possibile, gli ambienti HA robusti si affidano a strumenti dedicati per gestire la complessa coreografia richiesta per failover e switchover, gestendo automaticamente le modifiche di configurazione e la gestione dello stato del cluster.

Repmgr (Replication Manager)

repmgr è uno strumento potente e leggero che monitora la replica e facilita il failover manuale o automatico. I comandi chiave includono:

• Switchover: repmgr standby promote seguito da repmgr switchover --sibling-nodes-wait (per garantire il recupero).
• Failover: repmgr failover

Patroni

Patroni utilizza Distributed Consensus Stores (come etcd, ZooKeeper o Consul) per gestire lo stato del cluster, eleggendo automaticamente un nuovo Primario al rilevamento di un guasto. Patroni automatizza in gran parte sia gli switchover che i failover tramite chiamate API o operatori Kubernetes, riducendo drasticamente l'intervento manuale.

Esempio di utilizzo di Patroni (Comando di promozione concettuale):

# Attivazione di uno switchover tramite l'API REST di Patroni
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "standby_node_name"}'

Avviso sullo Split-Brain: Il pericolo maggiore durante il failover automatizzato è lo scenario di 'split-brain', in cui due nodi credono erroneamente di essere il Primario a causa della partizione di rete. Strumenti come Patroni mitigano questo problema utilizzando meccanismi di quorum, mentre le configurazioni manuali richiedono rigorosi meccanismi di fencing (come i controlli di alimentazione) per garantire che esista un solo Primario.

Riepilogo delle differenze

L'esecuzione di failover e switchover in PostgreSQL richiede una profonda comprensione dello stato del cluster e degli strumenti che lo gestiscono. Mentre gli switchover mirano alla perdita di dati zero attraverso il coordinamento, i failover danno priorità al ripristino rapido del servizio, spesso a scapito delle transazioni più recenti. La corretta impostazione dei parametri di replica e l'utilizzo di strumenti robusti per la gestione del cluster sono i capisaldi di una Alta Disponibilità di PostgreSQL affidabile.