repmgr manuell installieren und Master/Slave-Replikation einrichten

Übersicht

Dieses Tutorial beschreibt die Schritte 5–8 zur manuellen Installation und Konfiguration von repmgr für PostgreSQL (Beispielversion repmgr-1.1.0). Ziel ist eine einfache, getestete Master/Slave-Replikation mit Monitoring durch repmgrd.

Wichtige Pfade/Parameter:

• repmgr-Archiv: http://projects.2ndquadrant.it/sites/default/files/repmgr-1.1.0.tar.gz
• temporäres Verzeichnis: /tmp
• PostgreSQL-Datenverzeichnis: /var/lib/pgsql/data
• Beispiel-Datenbank: pgbench
• Port: 5432

Schritt 5. repmgr-Quellcode manuell installieren (auf Master und Slave)

1. Laden Sie repmgr herunter:

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

2. Vor dem Kompilieren benötigen Sie Build-Abhängigkeiten. Installieren Sie diese mit zypper:

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

3. Kompilieren und installieren Sie repmgr:

make USE_PGXS=1
make USE_PGXS=1 install

4. Prüfen Sie die Installation auf beiden Servern:

repmgr --version
repmgrd --version

Wichtig: Stellen Sie sicher, dass auf Master und Slave dieselben repmgr-Binärdateien (Versionen) vorhanden sind. Weiter geht es mit dem Klonen des Masters auf den Slave.

Schritt 6. Master-Datenbank auf Slave klonen [NUR SLAVE]

Wechseln Sie zum postgres-Benutzer und starten Sie das Klonen:

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

Während des Klonvorgangs sehen Sie Logausgaben, die den Fortschritt zeigen:

Starten Sie anschließend PostgreSQL auf dem Slave:

/etc/init.d/postgresql start

Hinweis: Bei Systemen mit systemd verwenden Sie stattdessen systemctl start postgresql.

Schritt 7. repmgr-Konfigurationsdatei auf Master und Slave anlegen

Erstellen Sie auf Master einen Ordner für repmgr und legen Sie /var/lib/pgsql/repmgr/repmgr.conf an (Pfad wie im Beispiel verwendet):

cluster=test
node=1
conninfo='host=pgmaster user=postgres dbname=pgbench'

Auf dem Slave analog:

cluster=test
node=2
conninfo='host=pgslave user=postgres dbname=pgbench'

Wichtige Hinweise:

• Verwenden Sie möglichst dedizierte repmgr-Benutzer (siehe Abschnitt Sicherheit und Rollen weiter unten).
• Achten Sie auf identische cluster-Namen auf allen Knoten.

Schritt 8. Master und Slave bei repmgr registrieren und Monitoring starten

Auf dem Master:

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

Auf dem Slave:

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

Prüfen Sie die Replikationsstatus-Tabelle:

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

In der Regel ist der Slave kurz (z. B. 1 Sekunde) hinter dem Master. Testen Sie die Replikation:

Auf dem Master:

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

Auf dem Slave:

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

Bingo — die Replikation funktioniert.

Verbesserungen und To‑Dos für die Zukunft

1. Verwenden Sie einen dedizierten repmgr-Benutzer statt systemweit postgres.
2. Beachten Sie einen bekannten Bug in älteren repmgr-Versionen; ein Fix ist in der upstream-Commit-Historie verfügbar:

https://github.com/greg2ndQuadrant/repmgr/commit/7427988628f754e57069453d65a71f79117c3a3d

3. Lesen Sie die repmgr-Dokumentation, um Promotion-Verfahren im Ausfallfall zuverlässig zu beherrschen.
4. Es gibt mehrere Möglichkeiten, Replikation und Failover zu prüfen — die PostgreSQL-Dokumentation listet Alternativen.
5. Lesen Sie die README-Datei im repmgr-Paket.

Bei Fragen können Sie den Autor kontaktieren: [email protected]

Mini-Methodik: So gehe ich vor (Kurz)

• Vorbereitung: Pakete & Abhängigkeiten installieren.
• Kompilieren & Installation: make USE_PGXS=1; install.
• Klonen: repmgr standby clone vom Slave aus.
• Konfiguration: repmgr.conf auf allen Knoten anlegen.
• Registrierung & Monitoring: repmgr master/standby register; repmgrd verwenden.
• Test: CREATE/INSERT auf Master, SELECT auf Slave prüfen.

Rollenbasierte Checklisten

Admin (Master):

• repmgr installieren und Version prüfen.
• repmgr.conf erstellen (node=1).
• Master in repmgr registrieren.
• Backup-Strategie prüfen.

Admin (Slave):

• repmgr installieren und Version prüfen.
• Datenverzeichnis leeren oder sichern.
• repmgr.conf erstellen (node=2).
• Klonen mit repmgr standby clone durchführen.
• Slave in repmgr registrieren.

Wann das Verfahren fehlschlägt (häufige Ursachen)

• Unterschiedliche repmgr/Postgres-Versionen zwischen Knoten. Lösung: Versionen angleichen.
• Netzwerkkonnektivität oder falsche conninfo-Einträge. Lösung: Hostnamen/IPs und Ports prüfen.
• Dateiberechtigungen im Datenverzeichnis. Lösung: Ownership und Rechte für postgres-Benutzer setzen.
• Unvollständiges WAL-Streaming oder fehlende archive_command. Lösung: WAL-Konfiguration prüfen.

Alternative Ansätze

• Paketbasierte Installation statt Kompilieren (Distribution-Pakete, z. B. RPM/DEB).
• Verwenden von pg_basebackup + replication slots für konsistente Backups.
• Externe Cluster-Manager (Patroni, Pacemaker) für automatisches Failover.

Kurze Troubleshooting-Anleitung

1. Logs prüfen: PostgreSQL- und repmgr-Logs (stdout, /var/log/postgresql/).
2. Netzwerk testen: ping/ss/psql-Verbindung von Slave zum Master.
3. Versionen prüfen: repmgr --version und psql --version.
4. Replikationsstatus anzeigen: SELECT * FROM repmgr_test.repl_status;.
5. Falls notwendig: Slave neu klonen.

Entscheidungshilfe für Failover (vereinfachter Ablauf)

flowchart TD
  A[Master ausgefallen?] -->|Nein| B[Keine Aktion]
  A -->|Ja| C{Kann repmgrd auto-promote?}
  C -->|Ja| D[Automatische Promotion durch repmgrd]
  C -->|Nein| E[Manuelle Promotion durch Admin]
  D --> F[Neuer Master betriebsbereit]
  E --> F

Sicherheits- und Rollenhinweise

• Legen Sie mindestens einen dedizierten repmgr-Benutzer mit eingeschränkten Rechten an.
• Schützen Sie conninfo-Zeilen (keine Klartext-Passwörter in öffentlichen Repositories).
• Beschränken Sie Netzwerkzugriffe auf Replikations-Ports per Firewall.

Kurzes Glossar (1‑Zeiler)

• repmgr: Open-Source-Werkzeug zur Verwaltung von PostgreSQL-Replikationsclusters und Failover.
• standby clone: repmgr-Befehl zum Klonen des Masters auf einen Standby.
• repmgrd: Daemon, der Überwachung und automatische Aktionen für repmgr übernimmt.

Zusammenfassung

• repmgr lässt sich aus dem Quellcode kompilieren und auf Master/Slave installieren.
• Nach Konfiguration und Registrierung funktioniert das Klonen und die Replikation wie erwartet.
• Tests nach Installation sind essentiell: Versionen prüfen, CREATE/INSERT auf Master, SELECT auf Slave.

Wichtige Links und Referenzen:

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

Wichtig: Lesen Sie die README im repmgr-Paket und die offizielle Dokumentation bevor Sie repmgr in Produktion einsetzen.