Diese Anleitung richtet sich an diejenigen, die mit wenig Aufwand eine PostgreSQL-Datenbank zur Verfügung stellen möchten, die auch beim Ausfall eines Servers ihre Daten nicht verliert und eine Art "Hochverfügbarkeit für Arme" anbietet.
Es existieren bereits Systeme, die eine "echte" Hochverfügbarkeit bietet, erzeugen aber ungleich mehr Aufwand und Systemkenntnisse. Wer also "echte" HA sucht, die auch Standortübergreifend funktioniert, dem sei zu "Patroni" geraten, oder aber gleich ein Cluster mit Corosync und Pacemaker
In diesem Beispiel wird ein Debian bzw. Ubuntu-System ausgegangen, das in 2 Instanzen bereit steht, die sich ihrerseits auch in demselben IP-Subnetz befinden. In dieser ersten Variante wird ein manuelles Failover vorausgesetzt. Wenn ein Server ausfällt, muss manuell der Cluster wieder in Synchronisation gebracht werden. Die meisten der zitierten Befehle und Aktionen erfolgen als User "root" (unter Ubuntu: "sudo- i"), wird ein anderer user verwendet, wird es explizit erwähnt!
1. Server-Installation
Zunächst werden zwei reale oder virtuelle Server mit dem Betriebssytem versehen. Hier wird nur eine minimale Installation notwendig, die "Server-Variante" des Ubuntu Linux ist völlig ausreichend. Wichtig ist die SecureShell und die Datenbank und die zugehörigen Tools. Der Befehl dazu:
apt-get install openssh-server openssh-client postgresql postgresql-client
2. Netzwerkkonfiguration
In diesem Beispiel werden die beiden Netz-Adressen manuell eingetragen. Das zugehörige Subnetz sei hier 192.168.10.0/24, Default Gateway ist 192.168.10.1. Namensserver sind in diesem speziellen Beispiel ohne Relevanz, weil wir uns auf die feste Konfiguration der Server verlassen wollen. In großen Umgebungen kann allerdings schwerlich auf DHCP und DNS verzichtet werden, doch behandeln wir hier nur eine minimal-Konfiguration. der erste Server sei hier pg-cluster1, der zweite pg-cluster2. Die Datei /etc/hosts bekommt daher diese beiden zusätzlichen Einträge:
192.168.10.11 pg-cluster1
192.168.10.12 pg-cluster2
3. Konfiguration des Master-Servers (pg-cluster1)
Für den Anfang wird der erste Rechner pg-cluster1 als Masterserver auserkoren, dager wird an diesem die Konfiguration begonnen:
Die Datenbank wird gestartet und der DB-Superuser konfiguriert. Der Einfachheit halber wird der User postgres mit einem einfachen Passwort ("admin") versehen und auch zur Replikation verwendet.
VORSICHT: DIESE EINSTELLUNG AUF KEINEN FALL FUER PRODUKTIVZWECKE VERWENDEN!!!!!
Der User postgres sollte gar nicht verwendet werden, sondern ein selbst erstellter user mit Superuser-Rechten, sowie ein dedizierter Replikationsuser.
template1=# alter user postgres with password 'admin';
ALTER ROLE
template1=#
Zum Test wird an dieser Stelle eine Datenbank angelegt, damit die Eigenschaften des Clusters und der Replikation überprüft werden können.
postgres@pg-cluster1:~$ createdb db01
postgres@pg-cluster1:~$ psql db01
psql (9.5.6)
Type "help" for help.
db01=# create table meintest(uid serial, description varchar(20));
CREATE TABLE
db01=# insert into meintest (description) values ('Erster');
INSERT 0 1
db01=# insert into meintest (description) values ('Zweiter');
INSERT 0 1
db01=# select * from meintest;
uid | description
-----+-------------
1 | Erster
2 | Zweiter
(2 rows)
Unter Root-Berechtigung wird nun die Haupt-Konfigurationsdatei /etc/postgresql/9.5/main/postgresql.conf verändert. Bitte ersetzen Sie die den Teil das Pfades, der die Versionsnummer darstellt (hier: 9.5) mit der bei Ihnen eingesetzten PostgreSQL-Version. In dieser Datei finden Sie bereits eine ganze Reihe Werte, die bereits durch die Installation gesetzt wurden. Die zu ändernden Zeilen sind diese:
listen_addresses = '*'
wal_level = logical
max_wal_senders = 10
hot_standby = on
wal_keep_segments = 8
hot_standby = on
den Rest belassen Sie so, wie Sie sie vorfinden!
Analog wird die Datei /etc/postgresql/9.5/main/pg_hba.conf angepasst, in dem diese beiden Zeilen hinzu gefügt werden:
host replication postgres 192.168.10.12/32 md5
host replication postgres 192.168.10.11/32 md5
Jetzt wird es zeit für einen Neustart der Datenbank:
systemctl restart postgresql
Die Datenbank sollte danach wieder vollständig verfügbar sein.
3. Konfiguration des Slave-Servers (pg-cluster2)
Auf dem Slave wird zunächst die vorhandene Datenbank gelöscht und mit einem Replikat des Master-Servers ersetzt. Zuerst wird die Datenbank gestoppt
systemctl stop postgresql
Ändern Sie dazu die Felder der /etc/postgresql/9.5/main/postgresql.conf wie beim Master-Server:
listen_addresses = '*'
wal_level = logical
max_wal_senders = 3
wal_keep_segments = 8
hot_standby = on
Auch die /etc/postgresql/9.5/main/pg_hba.conf wird ergänzt:
host replication postgres 192.168.10.11/32 md5
host replication postgres 192.168.10.12/32 md5
Dann erzeugen Sie als user "postgres" die Replikation. Zunächst werden alle Dateien der alten, nicht mehr benötigten Datenbank gelöscht:
rm -r var/lib/postgresql/9.5/main/*
Die gelöschten Dateien werden mit einem Replikat des Masterservers pg-cluster1 ersetzt. Dazu wird dieser Befehl verwendet:
pg_basebackup -D /var/lib/postgresql/9.5/main -h pg-cluster1 --checkpoint=fast --xlog-method=stream -R
Das Passwort ist hier 'admin'!
Hier wird automatisch die Datei recovery.conf erzeugt, die die Zugangsdaten zum Master-Server enthält. Wird dann der Postgres-Server wieder gestartet, begibt er sich automatisch in den Recovery-Modus, und ist auch durch das gesetzte hot_standby=on für den ReadOnly-Zugriff bereit. Die Datenbank wird wieder als User "root" gestartet:
systemctl start postgresql
Test: Auf dem Master wird eine Tabelle verändert:
insert into meintest (description) values ('Zweiter');
Auf dem Slave wird die Tabelle gelesen und die neue Zeile bereits angezeigt:
select * from meintest;
uid | description
-----+-------------
1 | Erster
2 | Zweiter
Wird eine Schreib-Operation auf dem Slave versucht, wird sie abgewiesen:
db01=# update meintest set description='Fuenf' where uid=5;
ERROR: cannot execute UPDATE in a read-only transaction
HAVARIE 1: Master fällt aus.
Auf dem alten Slave pg-cluster2 als user postgres
ausführen:
/usr/lib/postgresql/9.5/bin/pg_ctl -D/var/lib/postgresql/9.5/main promote
Fertig. Hier ist kein Restart nötig!!! Der Server ist ab sofort im RW-Modus und enthält nun die aktive Datenbank! Der alte Master (pg-cluster1) muss nun zum neuen Slave gemacht werden. Zunächst muss der alte Server irgendwie aus einem Backup gezogen, oder manuell nach obigen Schema nachgebaut werden. Im ersteren Fall darf der Server aber nicht "einfach so gestartet werden, sondern die Daten vom neuen Master übernommen werden. Das erfolgt mit diesen Schritten:
a)Sicherstellen das die DB nicht läuft:
systemctl stop postgresql
Weitere Befehle werden als User postgres ausgeführt (su - postgres):
b) Verzeichnis entsorgen
rm -r /var/lib/postgresql/9.5/main/*
c) Die Dateien /etc/postgresql/9.5/main/postgresql.conf und /etc/postgresql/9.5/main/pg_hba.conf nach obigen Vorbild kontrollieren und ggf. ändern.
Dateien replizieren:
pg_basebackup -D /var/lib/postgresql/9.5/main -h pg-cluster2 --checkpoint=fast --xlog-method=stream -R
Das Passwort ist hier wieder 'admin'!
d) Als User root wird die Datenbank wieder gestartet:
systemctl start postgresql
Damit ist der Server wieder vollständig.
HAVARIE 2: Slave fällt aus.
An dieser Stelle wird der Zustand des Clusters nicht verändert. Der Slave wird mit den obigen Befehlen unter Postgres wieder hergestellt:
rm -r /var/lib/postgresql/9.5/main/*
pg_basebackup -D /var/lib/postgresql/9.5/main -h pg-cluster1 --checkpoint=fast -x -P -R
Automatisches Verfahren
Das Verfahren für einen automatischen Wechsel des Master/Slave-Zustandes kann beim Starten geschehen und lässt sich im Pseudocode folgendermaßen beschreiben:
if [remote_db_avaliable]
then
if [local_db_is_slave]
then
if [remote_db_is_master]
then
start postgres
else
if [Quorum_avaliable]
then
Stop remote DB (STONITH)
Promote localDB
start postgres
else
Stop remote DB
STOP DB
fi
fi
else
if [remote_db_is_master]
then
Demote local DB
start postgres
else
start postgres
fi
fi
else
if [Quorum_avaliable]
then
if [local_db_is_slave]
then
Promote local DB
start postgres
else
start postgres
fi
else
STOP DB
fi
fi
Eine Abfrage auf den Master-/Slave-Zustand kann durch eine SQL-Abreage geschehen:
select pg_is_in_recovery();
-> "f" (false) ==> Master
-> "t" (true) ==> Slave
Alternativ kann per Shell Befehl daif Existenz der Datei recovery.con getestet werden:
test -f /etc/postgresql/9.5/main/recovery.conf
-> false ==> Master
-> true ==> Slave
Promote zum Master:
/usr/lib/postgresql/9.5/bin/pg_ctl -D/var/lib/postgresql/9.5/main promote
Demote zum Slave:
rm -r /var/lib/postgresql/9.5/main/*
pg_basebackup -D /var/lib/postgresql/9.5/main -h pg-cluster1 --checkpoint=fast -x -P -R