Guida passo-passo alla configurazione della replicazione in streaming di PostgreSQL

La replicazione in streaming è il meccanismo fondamentale per ottenere alta disponibilità (HA) e scalabilità in lettura negli ambienti PostgreSQL. Configurando un server primario (master) per inviare continuamente i record del Write-Ahead Log (WAL) a uno o più server di standby (replica), si garantisce la sincronizzazione dei dati con un ritardo minimo.

Questa guida completa illustra i passaggi essenziali necessari per stabilire una robusta replicazione in streaming asincrona. Copriamo le modifiche di configurazione necessarie sia sui server primari che su quelli di standby, utilizzando moderne funzionalità di PostgreSQL come pg_basebackup e i file segnale per una configurazione semplificata. Seguendo questo tutorial si otterrà una base affidabile per un robusto funzionamento di PostgreSQL.

Prerequisiti e configurazione dell'ambiente

Prima di iniziare, assicurarsi che i seguenti prerequisiti siano soddisfatti. Questa guida presuppone due server, Primario e Standby, che eseguono la stessa versione maggiore di PostgreSQL (si consiglia la versione 12 o più recente).

Server	Ruolo	Indirizzo IP (Esempio)
Primario	Fonte di verità	192.168.1.10
Standby	Replica	192.168.1.11

• Utente: È necessario disporre di accesso amministrativo (ad esempio, sudo o l'utente di sistema postgres) su entrambi i server.
• Rete: Il server di standby deve essere in grado di connettersi al server primario sulla porta di PostgreSQL (predefinita 5432).

Passaggio 1: Configurare il server primario

Il server primario deve essere configurato per generare e servire i file WAL per la replicazione.

1.1 Modificare postgresql.conf

Modificare il file di configurazione principale, tipicamente situato nella directory dei dati (ad esempio, /etc/postgresql/14/main/postgresql.conf), e impostare i seguenti parametri:

# Consente connessioni da altri host
listen_addresses = '*'

# Imposta il livello WAL su 'replica' o superiore
wal_level = replica

# Numero massimo di connessioni concorrenti da server di standby
max_wal_senders = 5 

# Controlla il numero di connessioni di standby che possono essere attive contemporaneamente
max_replication_slots = 5

# Richiesto per le query in sola lettura sullo standby (Hot Standby)
hot_standby = on

1.2 Creare un utente di replicazione dedicato

Per motivi di sicurezza, creare un utente specifico con l'attributo REPLICATION. Questo utente sarà utilizzato solo dal server di standby per recuperare i record WAL.

# Connettersi a PostgreSQL
psql -c "CREATE USER replica_user REPLICATION ENCRYPTED PASSWORD 'SuperSecurePassword123';"

1.3 Aggiornare l'autenticazione del client (pg_hba.conf)

Consentire all'utente di replicazione dall'indirizzo IP del server di standby di connettersi allo speciale pseudo-database replication.

# TIPO  DATABASE        UTENTE            INDIRIZZO                 METODO
host    replication     replica_user    192.168.1.11/32         md5

1.4 Riavviare il server primario

Applicare le modifiche riavviando il servizio PostgreSQL:

sudo systemctl restart postgresql

Passaggio 2: Preparare il server di standby

Prima di clonare i dati, assicurarsi che il servizio PostgreSQL dello standby sia fermato e che la sua directory dati esistente sia stata svuotata.

2.1 Arrestare il servizio PostgreSQL di standby

sudo systemctl stop postgresql

2.2 Svuotare la directory dei dati

Attenzione: Questo passaggio elimina permanentemente tutti i dati attualmente presenti nella directory dei dati dello standby. Confermare il percorso prima dell'esecuzione.

# Percorso di esempio per PG 14
PG_DATA=/var/lib/postgresql/14/main

sudo rm -rf $PG_DATA/*

2.3 Clonare i dati usando pg_basebackup

Usare pg_basebackup per creare una copia esatta della directory dei dati del primario. Il flag -R è cruciale in quanto genera automaticamente i file di configurazione necessari (standby.signal e primary_conninfo) per la replicazione in streaming (PostgreSQL 12+).

Eseguire questo comando sul server di standby:

PG_DATA=/var/lib/postgresql/14/main

sudo -u postgres pg_basebackup -h 192.168.1.10 -D $PG_DATA -U replica_user -P -v -R

Opzione	Descrizione
-h	Nome host/indirizzo IP del server primario.
-D	Percorso della directory dati locale.
-U	Nome utente per la replicazione (replica_user).
-P	Mostra avanzamento.
-v	Output dettagliato.
-R	Crea automaticamente un file di configurazione per la replicazione.

Passaggio 3: Configurare e avviare lo standby

3.1 Verificare la configurazione dello standby

Se è stato usato il flag -R nel Passaggio 2.3, pg_basebackup ha creato un file standby.signal e ha popolato l'impostazione primary_conninfo, solitamente in un file di configurazione generato chiamato postgresql.auto.conf all'interno della directory dei dati.

Verificare il contenuto della stringa primary_conninfo. Dovrebbe apparire simile a questa (controllare all'interno di $PG_DATA/postgresql.auto.conf):

primary_conninfo = 'host=192.168.1.10 user=replica_user password=SuperSecurePassword123 application_name=standby_node'

Suggerimento: Assicurarsi che la password sia inclusa in primary_conninfo o che si stia usando l'autenticazione basata su certificati. Se si usa pg_hba.conf con trust o cert, la password può essere omessa.

3.2 Avviare il servizio di standby

Poiché il file segnale richiesto (standby.signal) è presente nella directory dei dati, il servizio si avvierà in modalità standby di sola lettura e tenterà immediatamente di connettersi al primario.

sudo systemctl start postgresql

Passaggio 4: Verificare la replicazione in streaming

Dopo aver avviato lo standby, è necessario confermare che la connessione sia attiva e che la sincronizzazione dei dati stia avvenendo.

4.1 Verifica sul server primario

Connettersi al server primario ed eseguire una query sulla vista pg_stat_replication. Dovrebbe apparire una riga che rappresenta la connessione dal server di standby.

psql -c "SELECT client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn FROM pg_stat_replication;"

Output atteso (campi chiave):

• client_addr: Dovrebbe corrispondere all'IP del server di standby (ad esempio, 192.168.1.11).
• state: Dovrebbe essere streaming. Se mostra startup o catching up, attendere un momento. Se mostra walsender in avvio, siete vicini.
• sync_state: Dovrebbe essere async (per la replicazione asincrona standard).

4.2 Test della sincronizzazione dei dati

Per confermare il flusso di dati, eseguire una modifica sul primario e verificare immediatamente la sua esistenza sullo standby.

Sul primario:

CREATE TABLE replication_test (id serial primary key, message text);
INSERT INTO replication_test (message) VALUES ('Data synchronized successfully');

Sullo standby (sola lettura):

-- Questo deve avere successo senza errori
psql -c "SELECT * FROM replication_test;"

Se i dati sono visibili sullo standby, la replicazione in streaming è stata configurata e attivata con successo.

Migliori pratiche e risoluzione dei problemi

Connessione persistente: Slot di replicazione

Sebbene opzionali, gli slot di replicazione sono fortemente raccomandati. Uno slot di replicazione assicura che il server primario non scarti prematuramente i segmenti WAL necessari allo standby, anche se lo standby si disconnette temporaneamente.

Sul primario:

SELECT * FROM pg_create_physical_replication_slot('standby_slot_name');

Quindi, aggiornare primary_conninfo sullo standby per utilizzare questo slot:

primary_conninfo = 'host=192.168.1.10 user=replica_user ... application_name=standby_node **slotname=standby_slot_name**'

Attenzione: Gli slot di replicazione richiedono un attento monitoraggio. Se uno standby fallisce per un periodo prolungato, i file WAL accumulati protetti dallo slot possono causare un rapido riempimento dello spazio su disco del server primario.

Risoluzione dei problemi comuni

Problema	Causa potenziale	Soluzione
Standby bloccato in starting	Firewall di rete o pg_hba.conf errato sul primario.	Verificare che la porta 5432 sia aperta; confermare che la voce pg_hba.conf corrisponda all'IP e all'utente dello standby.
pg_basebackup fallisce con errore di autenticazione	Password errata o voce host mancante in pg_hba.conf.	Ricontrollare la password per replica_user; assicurarsi che il database primario sia riavviato dopo aver modificato pg_hba.conf.
Standby è di sola lettura	Questo è il comportamento previsto.	La presenza di standby.signal forza il server in modalità di ripristino.

Conclusione

La configurazione della replicazione in streaming è un passo critico nella costruzione di un'architettura PostgreSQL resiliente. Seguendo questi passaggi, avete configurato con successo una coppia primario-standby che garantisce la sincronizzazione continua dei dati, migliorando significativamente le capacità di alta disponibilità del vostro sistema. Il passo logico successivo è integrare una soluzione di monitoraggio e un meccanismo di failover (come Patroni o Repmgr) per automatizzare completamente la configurazione HA.