Padroneggiare la Replicazione di PostgreSQL: Tipi e Configurazione Spiegati

La replicazione di PostgreSQL mantiene un secondo server abbastanza vicino al primario da poter sopravvivere a guasti hardware, spostare il traffico di lettura o eseguire una migrazione controllata. Se il tuo database è una dipendenza di produzione, devi sapere quale modello di replicazione di PostgreSQL si adatta alla tua tolleranza al rischio prima che un nodo si guasti.

PostgreSQL offre due scelte comuni: replicazione streaming e replicazione logica. La replicazione streaming copia il WAL a livello di cluster fisico. La replicazione logica invia modifiche a livello di riga da tabelle selezionate attraverso pubblicazioni e sottoscrizioni.

Perché la Replicazione di PostgreSQL è Importante

La replicazione aiuta con quattro problemi operativi quotidiani:

Alta disponibilità: Se il primario si guasta, puoi promuovere un standby e puntare le applicazioni su di esso.
Ripristino di emergenza: Uno standby in un'altra posizione può proteggerti da un guasto a livello di sito.
Scalabilità in lettura: Le query di sola lettura possono essere eseguite su standby attivi invece che sul primario in scrittura.
Supporto alla migrazione: La replicazione logica può aiutare a spostare tabelle selezionate tra versioni di PostgreSQL o layout di database.

La replicazione non sostituisce il backup. Un bug, una migrazione errata o un DELETE accidentale possono replicarsi rapidamente. Mantieni backup testati e ripristino point-in-time insieme alla replicazione.

Replicazione Streaming (Replicazione Fisica)

La replicazione streaming è la forma più comune e fondamentale di replicazione in PostgreSQL. Funziona inviando i record del Write-Ahead Log (WAL) dal server primario a uno o più repliche. Questi record WAL rappresentano ogni modifica apportata al database. Le repliche applicano quindi questi record WAL ai propri file di dati, assicurando che rimangano coerenti con il primario.

Streaming Sincrono vs. Asincrono

La replicazione sincrona fa sì che il primario attenda uno o più standby sincroni prima di segnalare un commit al client. Il livello esatto di sicurezza dipende da synchronous_commit; ad esempio, attendere che il WAL sia scritto è diverso dall'attendere che venga riprodotto. Ottieni una protezione più forte contro la perdita di commit riconosciuti, ma ogni commit ora dipende dalla latenza della replica e della rete.

La replicazione asincrona consente al primario di eseguire il commit localmente e inviare il WAL alle repliche successivamente. È più veloce per le scritture, ma un crash del primario può perdere transazioni recenti che non avevano ancora raggiunto uno standby.

Configurazione della Replicazione Streaming (Esempio Asincrono)

La configurazione della replicazione streaming comporta la configurazione sia del server primario che della replica. Ecco una guida semplificata:

1. Configurare il Server Primario (`postgresql.conf` e `pg_hba.conf`)

Sul server primario, devi abilitare l'archiviazione WAL e le connessioni di replicazione.

Modifiche a postgresql.conf:
```
wal_level = replica  # o logical per replicazione logica
max_wal_senders = 5  # Numero di connessioni di replicazione concorrenti
wal_keep_size = 512MB # O wal_keep_segments per versioni precedenti
# Per replicazione sincrona, aggiungi:
# synchronous_standby_names = 'replica1,replica2'
# O per nome/priorità specifico del server:
# synchronous_standby_names = '1 (replica1), 2 (replica2)'
archive_mode = on
archive_command = 'test ! -f /path/to/wal_archive/%f && cp %p /path/to/wal_archive/%f'
```
- wal_level: Deve essere almeno replica per la replicazione streaming.
- max_wal_senders: Specifica quanti server standby possono connettersi simultaneamente.
- wal_keep_size: Impedisce che i file WAL vengano eliminati prima che le repliche possano recuperarli (un'alternativa più semplice a archive_command per configurazioni di base, ma l'archiviazione è raccomandata per la robustezza).
- archive_mode e archive_command: Utili per il ripristino point-in-time (PITR) e per le repliche che necessitano di vecchi WAL dopo essere rimaste indietro. In produzione, usa una destinazione di archivio reale o uno strumento di backup invece di un comando di copia locale.

Modifiche a pg_hba.conf:

Consenti alla replica di connettersi per la replicazione. Sostituisci replica_ip_address con l'IP effettivo della tua replica.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replication_user  replica_ip_address/32   md5

Dovrai anche creare un utente di replicazione:

-- Sul server primario:
CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

Dopo aver modificato questi file, ricarica la configurazione di PostgreSQL:

pg_ctl reload
# O riavvia PostgreSQL se necessario

2. Preparare il Server Replica

Prima di avviare la replica, deve avere una directory dati che sia una copia della directory dati del primario in un momento specifico. Il modo più semplice è usare pg_basebackup.

Ferma PostgreSQL sulla replica (se in esecuzione).
Esegui un backup di base:
```
# Assicurati che PGDATA sia vuoto o rimosso prima
pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P -R
```
- -h, -p, -U: Specifica i dettagli di connessione del server primario.
- -D: La directory dati per la replica.
- -Fp: Il formato è semplice.
- -Xs: Stream WAL durante il backup.
- -P: Mostra progresso.
- -R: Scrive le impostazioni di connessione dello standby e crea standby.signal per PostgreSQL 12 e successivi.
- Ti verrà chiesta la password per replication_user.

3. Configurare il Server Replica

Modifiche a postgresql.conf (per PG12+):

hot_standby = on # Consente query di sola lettura sulla replica
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

hot_standby: Abilita query di sola lettura sullo standby.
primary_conninfo: Stringa di connessione al server primario.

Versioni precedenti di PostgreSQL:

PostgreSQL 12 ha rimosso recovery.conf. Se mantieni un server più vecchio, crea recovery.conf nella directory dati della replica:
```
standby_mode = 'on'
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
# Se usi il ripristino da archivio invece dello streaming, specifica restore_command
# restore_command = 'cp /path/to/wal_archive/%f %p'
# recovery_target_timeline = 'latest'
```
Su PostgreSQL 12 e successivi, la modalità standby è controllata da standby.signal, e primary_conninfo di solito risiede in postgresql.auto.conf quando creata da pg_basebackup -R.

4. Avviare il Server Replica

Avvia il servizio PostgreSQL sulla replica. Si connetterà al primario, riceverà i record WAL e inizierà a sincronizzarsi. Puoi controllare i log per conferma.

Suggerimento: Per HA robusta, considera l'uso di strumenti come Patroni o repmgr, che automatizzano il failover e la gestione.

Replicazione Logica

La replicazione logica è una forma di replicazione più flessibile e granulare introdotta in PostgreSQL 10. Invece di replicare interi blocchi di dati o record WAL, replica le modifiche ai dati in base al loro significato logico (ad esempio, istruzioni INSERT, UPDATE, DELETE) a livello di riga. Ciò si ottiene decodificando i record WAL in un flusso di modifiche logiche.

Caratteristiche Chiave e Casi d'Uso:

Replicazione selettiva: Puoi scegliere quali tabelle replicare. Le versioni recenti di PostgreSQL supportano anche elenchi di colonne nelle pubblicazioni, ma controlla la versione del tuo server prima di fare affidamento su questa funzionalità.
Replicazione tra versioni: La replicazione logica può replicare dati tra diverse versioni principali di PostgreSQL.
Controllo dello schema: La replicazione logica non replica automaticamente il DDL. Crea tabelle corrispondenti e applica le migrazioni dello schema sul sottoscrittore.
Trasformazione dei dati: Sebbene non integrata, la replicazione logica fornisce una base per processi ETL (Estrai, Trasforma, Carica) più complessi.
Replicazione da un primario a una replica che non è un clone completo: Il database di destinazione non deve essere una copia fisica completa della sorgente.

Come Funziona:

Editore: Il database sorgente (primario) dove avvengono le modifiche ai dati. Necessita di wal_level = logical. Le modifiche vengono decodificate dal WAL in un flusso logico.
Pubblicazione: Un insieme denominato di tabelle sull'editore le cui modifiche verranno replicate.
Sottoscrittore: Il database di destinazione (replica) che riceve le modifiche.
Sottoscrizione: Una connessione sul sottoscrittore che si connette all'editore e applica le modifiche da una pubblicazione specifica.

Configurazione della Replicazione Logica

1. Configurare l'Editore (Server Primario)

Modifiche a postgresql.conf:

wal_level = logical
max_replication_slots = 10 # Per slot di replicazione logica
max_wal_senders = 10     # Dovrebbe essere almeno max_replication_slots

Creare una Pubblicazione:

-- Sul database editore:
CREATE PUBLICATION my_publication FOR TABLE 
    table1, 
    table2 
    WITH (publish = 'insert,update,delete');

-- O per tutte le tabelle:
-- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;

Ricarica la configurazione sull'editore.

2. Configurare il Sottoscrittore (Server Replica)

Assicurati che le tabelle di destinazione esistano: Il database sottoscrittore deve avere le tabelle di destinazione con lo stesso schema dell'editore. Puoi crearle manualmente o usare pg_dump per estrarre lo schema.
Creare una Sottoscrizione:
```
-- Sul database sottoscrittore:
CREATE SUBSCRIPTION my_subscription
    CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db'
    PUBLICATION my_publication;
```
replication_user necessita dei permessi appropriati sull'editore.

PostgreSQL creerà automaticamente uno slot di replicazione sull'editore e inizierà ad applicare le modifiche. Puoi monitorare lo stato della sottoscrizione usando pg_stat_subscription sul sottoscrittore.

Suggerimento: La replicazione logica utilizza l'infrastruttura di decodifica logica integrata di PostgreSQL. Non richiede un'estensione separata per pubblicazioni e sottoscrizioni di base.

Scegliere il Metodo di Replicazione Giusto

Replicazione Streaming: Ideale per alta disponibilità e ripristino di emergenza, dove hai bisogno di una copia esatta, byte per byte, del primario. È più semplice da configurare per la replicazione completa del database e fornisce la migliore scalabilità in lettura per repliche di sola lettura.
Replicazione Logica: Più adatta per distribuzione selettiva dei dati, migrazioni, aggiornamenti tra versioni o quando hai bisogno di replicare solo un sottoinsieme di dati. Consente scenari più complessi come la replicazione verso schemi diversi o l'esecuzione di trasformazioni dei dati.

Conclusione

Usa la replicazione streaming quando hai bisogno di uno standby completo per failover, ripristino di emergenza o traffico di sola lettura. Usa la replicazione logica quando hai bisogno di tabelle selezionate, migrazione tra versioni o movimento controllato di dati tra diversi database.

Prima di fidarti di una qualsiasi configurazione, esegui un drill di failover, controlla la gestione delle connessioni dell'applicazione, monitora il ritardo di replicazione e verifica che i backup si ripristinino ancora correttamente. La replicazione mantiene un altro server aggiornato; non sostituisce i test operativi.