Schritt für Schritt

Die folgende Anleitung richtet sich an PostgreSQL-Anwender, die mit den grundlegenden Verwaltungsarbeiten gut vertraut sind. Um ein PostgreSQL-Setup mit Streaming Replication/Hot Stand-by-Setup zu betreiben, braucht es nicht viel mehr als zwei Datenbanken mit möglichst gleicher PostgreSQL-Version. Es empfiehlt sich, einen gemeinsamen Bereich für archivierte WAL-Segmente einzurichten, zwingend notwendig ist das allerdings nicht. Das Beispiel startet mit einem PostgreSQL-Datenbankcluster, der neben den »postgres« und »template0/ template1«-Datenbanken eine eigene Datenbank für Testzwecke beinhaltet. Auf der Master-Seite ist ein neuer oder bestehender Datenbank-Superuser zu bestimmen, der für die Replikation verantwortlich sein soll. Damit sich die Slave-Server auch verbinden dürfen, ist in der »pg_hba.conf« ein neuer Eintrag die replizierenden Slaves zu ergänzen.

$ $EDITOR pg_hba.conf
# TYPE DATABASE USER CIDR‑ADDRESS METHOD
# Da replication ein reserviertes Wort ist, gehört es beim
# Benutzernamen zwischen Anführungen
host replication "replication" 10.211.55.0/24 md5

In der »postgresql.conf« sind einige Standardwerte anzupassen. Falls noch nicht geschehen ist dafür zu sorgen, dass sich die Slave-Server via TCP auch zur Datenbank verbinden können – der Parameter »listen_addresses« ist standardmäßig nur auf »localhost« gesetzt. Um die Anzahl der gleichzeitig verbundenen Replikations-Slaves zu begrenzen gibt es den Parameter »max_wal_senders«, der auf einen ausreichend hohen Wert für die jeweilige Umgebung zu setzen ist.

Der Parameter »wal_level« gibt an, wie viel Daten im WAL mitgeschrieben werden sollen. Um Hot Stand-by Server betreiben zu können, ist dieser Parameter von seiner Standardeinstellung »minimal« auf »hot_standby« zu setzen. Um die Anzahl der WAL-Segmente, die der Master vorhalten soll, festlegen zu können gibt es den Parameter »wal_keep_segements«. PostgreSQL verwaltet seine WAL-Segmente im Verzeichnis »$PGDATA/pg_xlog«. Normalerweise hält es nur so viele Segmente vor, wie es für den sicheren Betrieb benötigt. In den meisten Situationen sind das nur die Segmente, die Daten beinhalten, die noch nicht von einem Checkpoint in die Heap-Files übernommen wurden. Alle älteren Segmente werden entweder gelöscht oder umbenannt und wiederverwendet. Im Falle der Replikation kann dies zu Problemen führen, wenn einer der Slaves über einen längeren Zeitraum offline ist und keine neuen Segmente vom Master abholen konnte. Falls die Kette an WAL-Segmenten auf einem der Slaves unterbrochen wird, muss man die Slave-Datenbank durch eine frische Kopie vom Master neu initialisieren, bevor man die Replikation wieder starten kann. Welchen Wert man in der Praxis wählen soll, hängt von der Rate ab, mit der neue Segmente entstehen, und von der maximalen Ausfallzeit der Datenbankknoten. Wenn der verfügbare Speicherplatz am Master kein Problem darstellt, kann man hier ruhig deutlich höher zielen (Listing 1).

Listing 1: »postgresql.conf«

01  # PostgreSQL horcht auf allen konfigurierten IP‑Adressen
02  listen_addresses = '*'
03  # Der Master soll im WAL alle nötigen Informationen für den Hot Standby‑Betrieb
04  # mitschreiben
05  wal_level = hot_standby
06  # Wir erlauben bis zu 5 Slave Server zu verbinden
07  max_wal_senders = 5
08  # PostgreSQL hält auf jeden Fall 10 abgeschlossene WAL Segmente als
09  # Sicherheitsbuffer vor
10  wal_keep_segments = 10

Wer mag, kann sich auf die bisher von Log Shipping verwendeten WAL-Archivierungsmechanismen stützen, die mit Archive- und Restore-Kommando sowie einem gemeinsam erreichbaren Speicherplatz für die Segmente eine Endlos-Archivierung ermöglichen. Um das Setup nicht unnötig zu verkomplizieren, soll diese Variante hier nicht vertieft werden, detaillierte Informationen dazu sind in der PostgreSQL-Dokumentation zu finden [4].

Slave

Auf dem Slave-Server benötigt man zu allererst eine aktuelle Kopie der Datenbank des MasterServers. Sie lässt sich im laufenden Betrieb erstellen. Mit der Funktion »pg_start_backup()« veranlasst der Admin PostgreSQL, BackupEinträge im WAL zu vermerken. Danach kann er das ganze PostgreSQL- Datenverzeichnis am Stück kopieren. Die Wahl des Werkzeugs bleibt dabei jedem selbst überlassen (Listing 2). Ist das Kopieren beendet, kann man das Backup am Master mit dem Aufruf der Funktion »pg_ stop_backup()« abschließen. Die Warnung, die die Datenbank dabei ausgibt, weist darauf hin, dass die erstellte Kopie ohne die WAL-Files vom Master nicht konsistent ist. Da hier der Datenbestand aber zur Replikation und nicht zur Sicherung Verwendung findet, kann man diese Botschaft getrost ignorieren.

pgmaster:~# psql postgres ‑c "SELECT pg_stop_backup();"
pg_stop_backup ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 0/6078AA8 (1 row)

Listing 2: Backup

01  pgmaster:~# psql postgres ‑c "SELECT pg_start_backup('Kopie auf Slave', true);"
02   pg_start_backup
03  ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
04   0/6000020
05  (1 row)
06
07  pgmaster:~# rsync ‑av ‑‑delete ‑‑exclude postmaster.pid /var/ lib/postgresql/9.0/main/pgslave.local: /var/lib/postgresql/9.0/main
08  [..]

Nachdem der Admin nun eine Kopie der Daten hat, kann er sich um die Konfiguration des Slaves kümmern. In der »postgresql.conf« auf dem Slave ist lediglich der Parameter »hot_standby« zu aktivieren (»hot_standby = on«). Das erlaubt es dem Server auch im Recovery Modus Verbindungen mit lesenden Statements zuzulassen. Damit der Server allerdings auch weiterhin Änderungen vom Master übernimmt, gilt es ein File »recovery.conf« im PostgreSQL-Datenverzeichnis anzulegen. In der Recovery-Konfiguration ist der Stand-by-Mode zu aktivieren. Das ist für PostgreSQL das Signal, kontinuierlich weitere WAL-Segmente entweder über das Restore-Kommando oder über die Streaming Replication-Verbindung zu beziehen. Damit der Slave auch weiß, wo sich sein Master überhaupt befindet, muss der Parameter »primary_conninfo« alle notwendigen Daten für die Verbindung beinhalten (Listing 3). Nachdem der Slave auch konfiguriert worden ist, kann man ihn starten. Im Logfile sollte sich folgender Output finden:

LOG: database system was interrupted; last known up at 2010‑09‑12 18:52:06 CEST
LOG: entering stand‑by mode
LOG: redo starts at 0/1000020
LOG: record with zero length at 0/10027E8
LOG: streaming replication successfully connected to primary
LOG: consistent recovery state reached at 0/2000000
LOG: database system is ready to accept read only connections

Listing 3: »recovery.conf«

01  # Server bleibt nach dem Start im Recovery Modus und holt Daten vom Master
02  standby_mode = 'on'
03  # Verbindungsdaten für den Master‑Server
04  primary_conninfo = 'host=pgmaster.local port=5432 user=replication
05  password=replicate'

Der Redo-Record zeigt den Punkt, ab dem das WAL für einen konsistenten Zustand der Datenbank benötigt wird; die Zeile mit dem Eintrag »streaming replication« deutet darauf hin, dass die Verbindung zum Master erfolgreich aufgebaut wurde. Die beiden letzten Zeilen verkünden schließlich, dass die Datenbank einen konsistenten Zustand erreicht hat und ab sofort lesende Datenbankabfragen erlaubt. Ab diesem Zeitpunkt sollte der Inhalt beider Datenbankinstallationen identisch sein. Alle Datenbanken im replizierten Cluster, deren Inhalte, Benutzer, und so weiter sind auf beiden Maschinen gleich. In unserer Testdatenbank sollten jetzt alle Änderungen, die der Master durchführt, auch sofort auf dem Slave sichtbar werden.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019