Configurazione delle slot di failover in PostgreSQL-17

PostgreSQL 17 introduce gli failover slots che migliorano le configurazioni ad alta disponibilità. Uno slot di replica garantisce che i dati rimangano affidabili e coerenti tra i nodi durante la replica, mentre uno slot di failover garantisce coerenza tra i nodi, specificamente durante e dopo un failover.

Gli failover slots sono una potente funzionalità che assicura che la replica logica possa continuare senza interruzioni, anche dopo un failover su un server di standby. Utilizzare gli failover slots consente agli slot di replica logica di essere sincronizzati automaticamente tra i nodi primari e di standby, riducendo significativamente i tempi di inattività e la necessità di interventi manuali durante un failover.

Questa guida ti guiderà nella configurazione di un cluster PostgreSQL ad alta disponibilità utilizzando la nuova funzionalità di failover slots. Alla fine, avrai una configurazione di replica robusta in grado di gestire senza problemi un failover. 

Perché gli Failover Slots Sono Importanti da una Prospettiva Storica

Le Sfide in PostgreSQL 15

• Slot di Replica Legati al Nodo Primario: In PostgreSQL 15, gli slot di replica venivano creati solo sul server primario. Tutti gli slot di replica logica andavano persi se il server primario falliva, portando a significativi ritardi nella replica e perdita di dati.
• Gestione Manuale del Failover: Durante gli scenari di failover, gli amministratori ricreavano manualmente gli slot di replica sul nuovo server primario, il che aumentava la complessità, introduceva errori e prolungava i tempi di inattività.
• Sincronizzazione degli Slot Non Disponibile: I server di standby non avevano modo di conoscere gli slot di replicazione logica sul primario. Questa mancanza di sincronizzazione portava a un completo reset dei flussi di replicazione in caso di failover.

Miglioramenti in PostgreSQL 16

Decodifica Logica Minima

PostgreSQL 16 ha introdotto una funzione chiamata decodifica logica minima sui server di standby:

• Decodifica Minima sul Server di Standby: Questo ha permesso ai server di standby di decodificare i log WAL per prepararsi alla replicazione logica, abilitando slot pre-riscaldati da utilizzare in caso di failover.
• Failover più Veloce: Decodificando in anticipo le modifiche WAL sul server di standby, è stato possibile ridurre il ritardo di replicazione quando si promuoveva un server di standby a primario. Tuttavia, ciò richiedeva ancora alcune configurazioni manuali per garantire un failover fluido.

PostgreSQL 17: Il Cambiamento di Gioco – Slot di Failover

• Slot di Failover: L’introduzione degli slot di failover in PostgreSQL 17 elimina la necessità di intervento manuale sincronizzando automaticamente gli slot di replicazione logica tra i server primari e di standby.
• Sincronizzazione Automatica: Il nuovo worker di sincronizzazione degli slot assicura che gli slot abilitati per il failover (failover = true) siano sempre sincronizzati, anche mentre il nodo primario è attivo.
• Transizione senza soluzione di continuità: In caso di failover, il server standby può prendere il controllo come primario senza perdere alcuno slot di replica, garantendo zero perdita di dati e replicazione continua.

Creazione di un cluster ad alta disponibilità con slot di failover

Questa sezione ti guiderà nella creazione di un cluster ad alta disponibilità di PostgreSQL con slot di failover. Nel nostro esempio, utilizzeremo i seguenti nodi:

1. NodoA (Server Primario)
2. NodoB (Standby Fisico)
3. NodoC (Subscriber Logico)

Prerequisiti

Prima di iniziare, assicurati di avere:

• PostgreSQL 17 installato su tutti e tre i nodi.
• Accesso SSH senza password tra ciascun nodo.
• Una conoscenza di base di PostgreSQL, replicazione PostgreSQL e dei file di configurazione di PostgreSQL.

Passaggio 1: Configurazione del Nodo Primario (NodoA)

1.1 Inizializzare il cluster su NodeA

Dopo aver installato PostgreSQL sul nodo principale, inizializzare il cluster; è possibile utilizzare i seguenti comandi:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 Configurare la replica nel file postgresql.conf

Dopo aver inizializzato il cluster, modificare il file postgresql.conf, situato di default in /home/pgedge/nodeA/postgresql.conf. Impostare i valori dei seguenti parametri:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 Aggiornare il file pg_hba.conf per consentire l’accesso alla Replica

Il file pg_hba.conf gestisce l’autenticazione del client per il server PostgreSQL. Aggiungere la seguente voce a /home/pgedge/nodeA/pg_hba.conf per garantire l’accesso a un utente di replica:

host replication replicator 127.0.0.1/32 md5

Successivamente, ricaricare la configurazione:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 Creare un Utente di Replica

Successivamente, accedere a PostgreSQL e creare l’utente di replica:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 Creare una Tabella e Configurare una Pubblicazione

Successivamente, sarà necessario creare una tabella e creare una pubblicazione associata:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

Passaggio 2: Configurare il Secondario Fisico (NodeB)

2.1 Inizializzare NodeB

Dopo aver installato PostgreSQL, inizializzare NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 Creare un Backup di Base

Successivamente, utilizzare pg_basebackup per eseguire un backup del cluster:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 Configurare postgresql.conf su Node-B

Modificare il file postgresql.conf (posizionato in /home/pgedge/nodeB/postgresql.conf), impostando:

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3 Abilitare la Sincronizzazione dello Slot di Failover

Utilizzare il client psql per accedere a NodeB:

psql -d postgres -p 5433 

Successivamente, utilizzare le seguenti istruzioni per configurare la replica per NodeB:

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

Uscire dal client psql e riavviare NodeB:

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Verificare la Sincronizzazione dello Slot

Successivamente, riconnettersi a NodeB con psql e verificare che gli slot siano sincronizzati:

SELECT slot_name, failover, synced FROM pg_replication_slots;

Passaggio 3: Configurazione del Sottoscrittore Logico (NodeC)

3.1 Inizializzare il cluster e configurare NodeC

Dopo aver installato PostgreSQL, inizializzare il cluster; è possibile utilizzare i seguenti comandi:

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

Successivamente, modificare il file /home/pgedge/nodeC/postgresql.conf, impostando i seguenti valori dei parametri:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2 Creare una Sottoscrizione su NodeC

Utilizzare il seguente comando per creare una sottoscrizione su NodeC:

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

Passaggio 4: Simulazione del Failover e Garanzia di Continuità

È possibile utilizzare i seguenti comandi per simulare un failover e confermare che la replica continui e l’integrità dei dati sia preservata.

4.1 Simulare un Failover

Utilizzare i seguenti comandi per simulare un guasto di NodeA, seguito dalla promozione da standby a primario di NodeB:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2 Aggiornare la Sottoscrizione su NodeC

Dopo aver promosso nodeB, accedi a NodeC e aggiorna la connessione per riflettere che NodeB è ora il nodo primario:

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 Verifica la continuità dei dati

Per testare la replica, utilizza psql per accedere a Node-B (ora il primario):

INSERT INTO foo VALUES (3), (4);

Controlla la replica su Node-C:

SELECT * FROM foo;

Conclusione

La funzione di failover slot di PostgreSQL 17 consente un failover senza soluzione di continuità negli ambienti di replica logica. Seguendo i passaggi descritti in questa guida, puoi creare un cluster ad alta disponibilità che garantisce un flusso di dati ininterrotto, anche durante un guasto del server primario.

Ottimizzando le configurazioni e sfruttando le nuove capacità di PostgreSQL 17, puoi creare un’infrastruttura database resiliente ed efficiente per le tue applicazioni critiche.