PostgreSQL 9 bringt Replikation und HA - Seite 2

Den Slave initialisieren

Danach erstellt er auf dem Master einen Abzug der Datenbanken und synchronisiert diesen per Rsync auf einen Slave:

psql -c "SELECT pg_start_backup('master-backup')"
rsync -HPSav --exclude postmaster.pid --exclude postmaster.log data/* root@10.1.1.2:`pwd`/data/
psql -c "SELECT pg_stop_backup()"

Auf dem Slave steht dagegen in »/var/lib/pgsql/data/postgresql.conf« :

hot_standby = on
archive_mode = off
archive_command = ''

Und in »/var/lib/pgsql/data/recovery.conf« :

standby_mode = on
restore_command = 'rsync -a /var/lib/pgsql/data/pg_xlog_archive/%f %p'
primary_conninfo = 'host=10.1.1.1 port=5432user=postgres'
trigger_file = '/tmp/pgsql-replication.trigger'

Nach erfolgreicher Inbetriebnahme findet der Admin folgende Log-Einträge: Auf dem Master taucht der Slave bereits mit seiner IP auf und meldet »LOG: replication connection authorized: user=postgres host=10.1.1.2 port=55723« . In ähnlicher Weise meldet auch der Slave den Vollzug mit »LOG: streaming replication successfully connected to primary« . In der Prozessliste durch »ps -ef« schlägt sich das funktionierende Setup ebenfalls nieder (Abbildung 2).

Abbildung 2: Nachdem die Verbindung zwischen Master und Slave besteht, zeigt auch die Prozessliste die zuletzt gestreamte Log-Position.

Ab diesem Moment repliziert PostgreSQL alle Daten vom Master an den oder die Slaves. Von denen kann jetzt bereits jeder im schlimmsten Fall zu einem Master werden. Der Kasten "Best Practices bei DB-Replikation" gibt grundsätzliche Tipps nicht nur für solche Setups.

Best Practices bei DB-Replikation

Die Natur der Datenreplikation ist durchaus komplex, man denke nur an Themen wie ACID- oder AKID-Konformität. Doch einige Vorgaben haben sich als elementarer Grundstock für den erfolgreichen Betrieb herauskristallisiert. Der Admin sollte Folgendes beachten:

Generell UTC verwenden und auf Zeitzonen mit Sommerzeit (DST, Daylight Savings Time) verzichten.
Seine Uhren mit NTP und mehreren Zeitservern synchronisieren.
Möglichst identische Systeme mit der gleichen Systemkonfiguration verwenden.
Klare Namen an die Systeme vergeben. Bezeichner wie »master« und »slave« sind denkbar ungeeignet und erzeugen schon bei einem Switch der Datenbanken-Rollen Konfusion.
Die Replikationsstände regelmäßig überwachen. Auseinanderdriftende Datenbestände verursachen unvorhersehbare Probleme.

Beim letzten Punkt ist es für den Datenbank-Admin sinnvoll, auf dem Master mit »SELECT pg_current_xlog_location();« den aktuellen Datenbestand (anhand der aktuellen Position im Log) abzufragen. Den vergleicht er mit der letzten empfangenen Log-Position auf dem Slave (»SELECT pg_last_xlog_receive_location();« ) und dessen aktueller Log-Position (»SELECT pg_last_xlog_replay_location();« , dieser Stand ist wirklich auf der Platte).

In-Place Upgrades

Wo früher Admins für ein Datenbank-Upgrade noch »pg_dump« und »pg_restore« oder im besten Falle den Pg-Migrator [3] verwenden mussten, kommt heute »pg_upgrade« zum Einsatz und verkürzt die Wartungsfenster für große Datenbanken bei einem sicheren Upgrade beträchtlich. Selbst nach einem empfohlenen »vacuumdb --all --analyze« sind auch größere Datenbestände eher in Minuten als Stunden auf den aktuellen Stand gebracht.