Installare repmgr per PostgreSQL: master e replica

Questo articolo spiega come compilare, installare e configurare repmgr su un server master e su una replica (standby) PostgreSQL. Include i comandi passo passo, verifiche, test di replica, suggerimenti per il failover e checklist operative per amministratori.

Cos’è repmgr (breve definizione)

repmgr è uno strumento open source per gestire la replica e il failover di PostgreSQL. Facilita registrazione dei nodi, monitoraggio e promozione della replica in caso di errore del master.

Prima di iniziare — prerequisiti

Accesso root o sudo sui server master e replica.
Utente PostgreSQL (tipicamente postgres) configurato.
PostgreSQL installato e funzionante su master e replica.
Connettività di rete tra i nodi (porte PostgreSQL aperte, default 5432).
Compilatore e librerie di sviluppo per compilare repmgr dal sorgente.

Importante: durante la procedura si lavora sul master e sulla replica; per alcune azioni (es. clone) eseguire i comandi solo sul nodo designato.

Fase 5. Installare repmgr dai sorgenti su master e replica

Scarica il pacchetto repmgr (esempio: repmgr-1.1.0.tar.gz) in /tmp sul master e sulla replica:

wget http://projects.2ndquadrant.it/sites/default/files/repmgr-1.1.0.tar.gz -O /tmp/repmgr-1.1.0.tar.gz

Prima di compilare repmgr è necessario installare i pacchetti di sviluppo richiesti. Su un sistema basato su openSUSE/SUSE (zypper):

zypper install make gcc postgresql-devel libxslt-devel pam-devel libopenssl-devel krb5-devel

Output del comando zypper che mostra i pacchetti installati

Estrai, compila e installa repmgr:

cd /tmp
tar xzf repmgr-1.1.0.tar.gz
cd repmgr-1.1.0
make USE_PGXS=1
make USE_PGXS=1 install

Schermata della compilazione e installazione di repmgr

Verifica l’installazione controllando le versioni:

repmgr --version
repmgrd --version

Esegui queste verifiche sia sul master sia sulla replica. Se i comandi producono output con la versione, l’installazione è avvenuta correttamente.

Fase 6. Clonare il database master sulla replica (esegui solo sulla replica)

Passa all’utente postgres e avvia il clone della base dati master nel nodo standby:

su - postgres
repmgr -D /var/lib/pgsql/data -d pgbench -p 5432 -R postgres --verbose standby clone pgmaster

Vedrai messaggi di log che indicano il trasferimento dei file e la sincronizzazione del WAL.

Log del processo di clone della replica

Avvia il servizio PostgreSQL sulla replica:

/etc/init.d/postgresql start

Nota: se usi systemd, il comando è systemctl start postgresql.

Fase 7. Configurare repmgr su master e replica

Crea la directory per repmgr e il file di configurazione su entrambi i nodi. Esempio per il master (modifica parametri secondo il tuo ambiente):

mkdir -p /var/lib/pgsql/repmgr
cat > /var/lib/pgsql/repmgr/repmgr.conf <<'EOF'
cluster=test
node=1
conninfo='host=pgmaster user=postgres dbname=pgbench'
EOF

Esempio sul nodo replica:

mkdir -p /var/lib/pgsql/repmgr
cat > /var/lib/pgsql/repmgr/repmgr.conf <<'EOF'
cluster=test
node=2
conninfo='host=pgslave user=postgres dbname=pgbench'
EOF

Spiegazione rapida dei campi principali:

cluster: nome logico del cluster repmgr.
node: identificatore numerico del nodo.
conninfo: stringa di connessione libpq; host può essere hostname o IP.

Important: assicurati che l’utente e le autorizzazioni nel database permettano le connessioni tra i nodi.

Fase 8. Registrare i nodi e avviare il monitoraggio

Sul master registra il nodo master:

repmgr -f /var/lib/pgsql/repmgr/repmgr.conf --verbose master register

Sulla replica registra il nodo standby:

repmgr -f /var/lib/pgsql/repmgr/repmgr.conf --verbose standby register

Controlla lo stato della replica con psql (esegui su uno dei nodi o dove hai accesso):

psql pgbench -c 'select * from repmgr_test.repl_status'

Dovresti osservare che la replica è leggermente indietro rispetto al master (esempio: ~1 secondo). Questo comportamento è normale e dipende dal carico e dalla latenza.

Test di replica finale

Esegui alcuni comandi sul master e verifica che i dati arrivino sulla replica.

Sul master:

psql pgbench -c "create table test ( test varchar(30));"
psql pgbench -c "insert into test values ( 'test123');"

Poi sulla replica:

psql -h pgslave pgbench -c "select * from test"

Verifica della tabella test sulla replica

Se la query sulla replica restituisce i dati inseriti sul master, la replica funziona correttamente.

Cosa migliorare e punti da controllare in futuro

Questa guida è una configurazione rapida. Elementi da rivedere o migliorare:

Usare un utente dedicato per repmgr (non l’utente postgres) e limitare i privilegi.
Correggere eventuali bug noti in repmgr (consultare le issue upstream e le patch disponibili).
Studiare e testare la procedura di promozione della replica (promote) e il failover automatico.
Considerare meccanismi di backup regolari e monitoraggio integrato.
Leggere sempre il README e la documentazione ufficiale di repmgr.

Link utili:

2ndQuadrant repmgr: http://projects.2ndquadrant.com/repmgr
PostgreSQL Hot Standby: http://wiki.postgresql.org/wiki/Hot_Standby
Binary Replication Tutorial: http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial

Troubleshooting comune e contromisure

Errore di connessione tra nodi: verificare pg_hba.conf, firewall e che il servizio PostgreSQL ascolti sull’interfaccia corretta.
Replica rimane indietro di molti secondi: controllare I/O e latenza di rete, carico del master, e configurazione wal_level e max_wal_senders.
Problemi di permessi con repmgr: usare un ruolo con permessi corretti oppure configurare un utente repmgr dedicato.

Quando repmgr può fallire (esempi)

Replica corrotta a causa di filesystem o arresti improvvisi non gestiti: in questi casi è preferibile ricreare la replica con un nuovo clone.
Configurazione errata del conninfo o del cluster: repmgr non riuscirà a registrare i nodi.
Versioni incompatibili di PostgreSQL e repmgr: assicurarsi che la versione di repmgr sia compatibile con la versione di PostgreSQL in uso.

Approcci alternativi

Utilizzare la replica nativa di PostgreSQL (streaming replication) gestita manualmente senza repmgr.
Soluzioni di orchestration come Patroni o Stolon per failover automatico con eccellenti meccanismi di consenso.
Soluzioni commerciali o gestite (cloud) che forniscono replica e failover come servizio.

Checklist basata sui ruoli

Amministratore di sistema / DBA:

Installare pacchetti di sviluppo e compilare repmgr.
Configurare repmgr.conf e directory di lavoro.
Verificare con repmgr –version e repmgrd –version.
Registrare master e replica e testare promozione.

Sviluppatore/operazioni:

Eseguire test di inserimento per verificare replicazione dei dati.
Testare procedure di rollback e failback in ambiente di staging.

Security officer:

Verificare che l’utente repmgr abbia privilegi minimi.
Controllare cifratura delle connessioni (SSL) tra nodi, se necessaria.

Mini-runbook per incidenti (failover manuale rapido)

Verificare che il master sia effettivamente down (controllare log e metriche).
Se il master è irrecuperabile, promuovere la replica principale:

repmgr -f /var/lib/pgsql/repmgr/repmgr.conf standby promote

Aggiornare le applicazioni/client per puntare al nuovo master.
Se possibile, ripristinare il server originale come replica dopo la ricostruzione.

Criteri di accettazione

repmgr è installato e le versioni sono confermate su entrambi i nodi.
La replica può essere clonata e avviata senza errori.
I dati inseriti sul master sono visibili sulla replica entro un ritardo accettabile.
I comandi di registrazione e promozione repmgr funzionano come previsto.

1-line Glossario

master: nodo primario che accetta scritture; replica/standby: nodo che applica WAL e serve letture di sola lettura; repmgr: tool per gestione replica e failover.

Note di sicurezza e privacy

Limitare l’accesso di rete ai soli host necessari e utilizzare SSL per connessioni tra nodi quando possibile.
Non esporre credenziali in chiaro nei file di configurazione accessibili a utenti non privilegiati.
Eseguire backup regolari; la replica non sostituisce la strategia di backup.

Annuncio breve (per comunicazione interna)

Abbiamo installato e configurato repmgr per la replica PostgreSQL tra i nodi pgmaster e pgslave. La replica è stata clonata con successo e verificata con query di test; aggiungeremo un utente dedicato per repmgr e una procedura di failover testata in ambiente di staging.

Riferimenti e contatti

Per domande e segnalazioni, consultare la documentazione ufficiale repmgr e le pagine wiki PostgreSQL. Se vuoi discutere le scelte architetturali, contatta il team DBA.

Installare repmgr su server master e replica (PostgreSQL)