Installare repmgr su server master e replica (PostgreSQL)

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

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

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.

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"

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:

1. Usare un utente dedicato per repmgr (non l’utente postgres) e limitare i privilegi.
2. Correggere eventuali bug noti in repmgr (consultare le issue upstream e le patch disponibili).
3. Studiare e testare la procedura di promozione della replica (promote) e il failover automatico.
4. Considerare meccanismi di backup regolari e monitoraggio integrato.
5. 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)

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

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

3. Aggiornare le applicazioni/client per puntare al nuovo master.
4. 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.