• http://burger-ag.de/postgresql_replikation.whtml
• Slony-I (seit Ver. 1.1 für PostgreSQL erhältlich; warm-Standby)
• Replikation mit PostgreSQL 9.0 (Streaming Replication: WAL-Shipping / in 8.5 cold-Standby; in 9.0 auch warm-Standby)

• http://www.golem.de/1109/86389.html
• http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.1

Mit Postgresql 9.1 ist erstmals die Möglichkeit einer synchronen Replikation vorhanden. Dabei wird eine Transaktion vom Master erst dann abgeschlossen, wenn sie mindestens auf einem Slave angekommen ist. Das soll einen Datenverlust verhindern, falls ein Master abstürzt, noch bevor ein Slave die Daten erhalten hat. Gegenüber der bisher vorhandenen asynchronen Replikation verringert sich jedoch die Schreibgeschwindigkeit.

Die Serializable Snapshot Isolation emuliert eine serielle Ausführung von Transaktionen. Damit sollen parallel ausgeführte Transaktionen zu keinem anderen Ergebnis kommen als seriell ausgeführte. Ebenfalls neu ist die Option Unlogged beim Erstellen einer Tabelle. Der Inhalt solcher "Unlogged Tables" wird nicht in einem Write-Ahead-Log erfasst. Dies führt wiederum zu einem Geschwindigkeitszuwachs, aber auch zu einem potenziellen Datenverlust bei einem Absturz.

Webinar: Beginner's Guide to High Availability for Postgres - German
PostgreSQL - Replikation

Bei der Streaming-Replikation kann man auch eine synchrone Replikation einschalten.
  synchronous_commit=on
  synchronous_commit=remote_apply

View:
  Master:  pg_stat_replication
  Standby: pg_wal_reciver

Webinar: Online Upgrade Using Logical Replication

• Qwant: postgresql streaming replication step by step
  • How to Set Up Streaming Replication to Keep Your PostgreSQL Database Performant and Up-to-Date
  • PostgreSQL + HAProxy

• heise 03.05.2010 15:05

Fünf Jahre nach dem Erscheinen von Version 8 macht PostgreSQL einen großen Versionssprung: Die Entwickler der freien Datenbank legen eine Beta-Version mit der Releasenummer 9.0 vor. Ihr wichtigstes neues Feature ist die erstmals integrierte Replikationsfunktion, die aus den Teilen "Hot Standby" und "Streaming Replication" besteht.

Streaming Replication schickt alle WAL-Einträge (Write Ahead Log) vom Master zum Slave. Dadurch, so die PostgreSQL-Entwickler, gebe es nur noch einen kleinen zeitlichen Versatz zwischen den Datenbeständen auf Master- und Slave-Maschinen.

Weitere Änderungen sind eine verbesserte LISTEN/NOTIFY-Technik, die Events innerhalb der Datenbank schneller zustellen soll. NOTIFY kann einen String (Payload) an den Listener weiterreichen. Anonyme SQL-Prozeduren lassen sich per DO definieren; die Ausführung von Triggern darf von Bedingungen abhängen. Stored Procedures können in Python 3 geschrieben werden, bei der PL/Perl-Implementierung gab es Verbesserungen. So sind jetzt use strict und require in Perl-Prozeduren zulässig. Mit EXCLUDE können Entwickler im CREATE TABLE-Statement Anforderungen an die Daten vorgeben, die über herkömmliche Constraints hinausgehen. Als Beispiel für die Verwendung von EXCLUDE nennt die Dokumentation etwa die Bedingung, dass in einer Tabelle mit geografischen Daten keine Kreise überlappen dürfen. Die Release Notes beschreiben alle Änderungen ausführlich.

Wer seine Daten von einer Vorgängerversion auf PostgreSQL 9 migrieren will, muss sie mit pg_dump exportieren und anschließend in die neue Version importieren. Alternativ ist ein Upgrade des Datenverzeichnisses mit pg_migrator möglich. Der Quellcode der Betaversion ist ebenso online erhältlich wie ein Windows-Installer und Binärpakete für einige andere Plattformen. (ck)

• Mo, 3. Mai 2010, 17:21

Die Entwickler der freien Datenbank PostgreSQL haben die erste Betaversion von Version 9.0 zum Testen bereitgestellt. Eingebaute Replikation und viele weitere Neuerungen sollen PostgreSQL zu noch mehr Verbreitung verhelfen.

Von Hans-Joachim Baader

Die Entwicklung von PostgreSQL 9.0 begann mit der Version 8.5 Alpha1, womit erstmals in der Projektgeschichte eine Alphaversion zum Testen bereitgestellt wurde. Mit der vierten Alphaversion wurde die Versionsnummer auf 9.0 geändert.

PostgreSQL 9.0 Beta soll zahlreiche Neuerungen bringen, die auf teils jahrelange Wünsche der Benutzer zurückgehen. Erstmals wird ein Replikationsmechanismus eingebaut sein. Interne Ereignisse werden schneller weitergeleitet und verarbeitet. In der DO-Anweisung sind nun anonyme Prozedurblöcke erlaubt. Spaltenspezifische, konditionale und SQL-konforme Trigger sind jetzt möglich. Die Einbindung der Sprachen Python und Perl als PL/Python und PL/Perl wurde verbessert, so kann nun auch Python 3 verwendet werden. Eindeutigkeitsbedingungen können nun auch an nicht-skalare Daten gestellt werden.

Die Unterstützung für Schlüssel-Wert-Paare wurde verbessert. Joins in Abfragen können automatisch wegoptimiert werden, was besonders Abfragen zugute kommen soll, die von Werkzeugen für objektrelationale Abbildungen erzeugt wurden. Außerdem kann das System unter 64-Bit-Windows jetzt im 64-Bit-Modus laufen. Darüber hinaus gab es weitere Verbesserungen, die zusammenfassend und im Detail in den Release Notes aufgeführt werden. Die Weiterentwicklung der Datenbank führte zu eine Reihe von kleineren Inkompatibilitäten. Zum Update auf die neue Version ist ein vollständiger Dump und Restore der Daten nötig, was aber auch schon früher meist der Fall war.

PostgreSQL baut auf eine fast 20-jährige Entwicklung auf, welche an der University of California in Berkeley begann und ursprünglich das Ziel hatte, einen Nachfolger für Ingres zu schaffen. Die erste Version von Postgres erschien 1989, wurde 1994 um einen SQL-Interpreter erweitert und in Postgres95 umbenannt. 1996 wurde die Entwicklung forciert, verbunden mit einem Wechsel des Namens zu PostgreSQL. Die erste Version mit diesem Namen war 6.0.

Das Datenbanksystem ist weitgehend konform mit den Standards SQL92, SQL99 und SQL2003 und bietet Schnittstellen zu vielen Programmiersprachen, unter anderem C, C++, Java/JDBC, Tcl, PHP, Perl, Python, Ruby und ODBC. Aufgrund der langjährigen Unterstützung von umfangreichen Leistungsmerkmalen im Unternehmens-Bereich, unter anderem Transaktionen, Funktionen, Trigger und Unterabfragen, wird PostgreSQL heute von vielen Unternehmen und Behörden eingesetzt. PostgreSQL steht unter der BSD-Lizenz.

• http://www.howtoforge.com/how-to-set-up-a-postgresql-9.0-hot-standby-streaming-replication-server-with-repmgr-on-opensuse-11.4

listen_addresses = "*"
wal_level = hot_standby
checkpoint_segments=30
archive_mode=on
archive_command='cd .'
max_wal_senders=2
wal_keep_segments=5000
hot_standby=on

host all all 192.168.5.0/24 trust
host replication all 192.168.5.0/24 trust

⇒ Time to install the repmgr management program:

• http://www.howtoforge.com/how-to-set-up-a-postgresql-9.0-hot-standby-streaming-replication-server-with-repmgr-on-opensuse-11.4-p2

Clone master database to slave (or standby server) [SLAVE ONLY] (Diese Schritte wird nur auf dem slave ausgeführt!):

# su - postgres
# repmgr -D /var/lib/pgsql/data -d pgbench -p 5432 -R postgres --verbose standby clone pgmaster
# exit
# /etc/init.d/postgresql start

# vi repmgr.conf

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

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

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

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

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

# psql pgbench -c "create table test ( test varchar(30));"
# psql pgbench -c "insert into test values ( 'test123');"
# psql -h pgslave pgbench -c "select * from test"

PostgreSQL Agenda 2010

Von Bernd Helmle am 4.02.10 14:53

PostgreSQL plant dieses Jahr mehrere große Schritte: die Veröffentlichung der Version 9.0 steht vor der Tür, während einige ältere Versionen das Ende der Lebenszeit erreichen.

PostgreSQL wird im Jahr 2010 mit der Version 9.0 nach längerer Zeit wieder einen großen Versionssprung auf eine neue Hauptversion vollziehen: eine Erhöhung auf die Version 9.0, die das Release als wichtigen Meilenstein kennzeichnen soll, steht an. Ein wichtiger Punkt sind dabei erweiterte Funktionen für den Betrieb von Standby-Servern im Nur-Lese-Modus (Hot Standby) sowie erstmals eine integrierte Replikationslösung.

Hot Standby wird erstmals einer PostgreSQL-Instanz ermöglichen, Leseanfragen auf sogenannten Standby-Knoten entgegenzunehmen. Das grundlegende Prinzip ist dasselbe, das seit Version 8.0 unter dem Namen PITR (Point In Time Recovery, Wiederherstellen bis zu einem bestimmten Zeitpunkt) bzw. WAL-Shipping bekannt war: Hierbei wird eine Kopie der Datenbank mit den anfallenden Transaktionslogs, dem sogenannten WAL (Write Ahead Log) in kontinuierlichen Intervallen mit allen Änderungen der Hauptdatenbank aktuell gehalten. Dies entspricht einem inkrementellem Nachziehen aller Änderungen, die seit dem Aufsetzen des Standby-Knotens auf dem Hauptknoten vorgenommen wurden. Bisher war dieses Prinzip als Warm Standby implementiert, d.h. die Datenbank auf dem Standby-Knoten war nicht für Anwendungen nutzbar. Mit Hot Standby besteht nun die Möglichkeit, Transaktionen auf diesem Knoten auszuführen, solange diese keine schreibenden Operationen vornehmen. Interessant ist dies vor allem für hochverfügbare PostgreSQL-Systeme oder umfangreichen Auswertungen, die auf einem separaten Knoten laufen können.

Lange war man in der PostgreSQL-Gemeinde unter den Entwicklern der Meinung, dass eine integrierte Replikation aufgrund der vielfältigen Anforderungen und Einsatzszenarien eine für die Entwickler schwer zu wartende Infrastruktur darstellt. Die Flexibilität und Sicherheit, die man von solchen Lösungen erwartet, können durch spezialisierte, externe Lösungen in deutlich vielfältiger Form implementiert werden. In den letzten Jahren hat sich jedoch auch dank der umfangreichen Resonanz von Nutzern herauskristallisiert, dass ein Großteil der gewünschten Funktionalität vor allem im Bereich der Hochverfügbarkeit lokalisiert ist. Nicht zuletzt aufgrund des Einsatzes von PostgreSQL in Bereichen von Datenmengen bis zu Hunderten von Gigabytes, die in einigen Unternehmen bereits alltäglich sind, war eine integrierte Lösung hierfür nicht mehr wegzudenken. Des weiteren ist die Verfügbarkeit einer integrierten Replikationslösung für viele Datenzentren eine wichtige Entscheidungsgrundlage.

Mit Streaming Replication erhält PostgreSQL nun eine integrierte Lösung für asynchrone Replikation von einem primären Datenbankserver (les- und schreibbar) auf mehrere sekundäre Server (nur lesbar). Diese Funktionalität basiert in Teilen auf der mit WAL-Shipping geschaffenen Infrastruktur, ermöglicht jedoch die Replikation von Transaktionen in deutlich geringeren Intervallen, indem die anfallenden Daten direkt vom primären an den sekundären Server gesendet werden (Daher die Bezeichnung Streaming). Ferner gestattet Streaming Replication die einfache Implementierung von PostgreSQL-Clustern mit mehreren Knoten gleichzeitig. Dies ist zwar auch mit Hot Standby Lösungen möglich, erfordert jedoch deutlich mehr Aufwand. Da die replizierenden Daten auf den Informationen des WAL basieren, ist diese Lösung äußerst robust. Im Moment sind hiermit jedoch Einsatzszenarien wie partiell replizierte Datenbanken oder modifizierte Datenbankschemata auf den einzelnen replizierten Knoten nicht möglich. Dies ist aber nach wie vor durch Lösungen wie Slony-I, Londiste oder Bucardo ohne Weiteres realisierbar.

2010 wird auch das Ende für einige PostgreSQL Versionen einläuten. Erstmals laufen drei Hauptversionen im selben Jahr gleichzeitig aus:

• PostgreSQL 7.4, Juli 2010
• PostgreSQL 8.0, Juli 2010
• PostgreSQL 8.1, November 2010

Für die Varianten für Windows lief die Unterstützung von PostgreSQL 8.0 und 8.1 bereits mit dem Erscheinen von PostgreSQL 8.3 im Februar 2008 aus. PostgreSQL 8.0 war das erste Release, das unter Windows nativ ausgeführt werden konnte, jedoch wurden im Laufe der Entwicklung viele Fehler behoben, die nicht mehr in die alten Versionen zurückgeführt werden konnten. Windowsnutzer müssen also schon seit geraumer Zeit mit mindestens PostgreSQL 8.2 fahren. Nun kommt auch das offizielle Ende der Unterstützung für alle anderen unterstützten Plattformen, und auch das letzte der 7er-Releases, PostgreSQL 7.4 wird nach 7 Jahren auslaufen. "Auslaufen" bedeutet im Falle von PostgreSQL in erster Linie, dass keine neuen Binärpakete oder Releases explizit angefertigt werden oder aufwändige Fixes nicht mehr portiert werden. Dennoch bleibt der Quelltext nach wie vor verfügbar. Die PostgreSQL Entwicklergruppe legt in der Regel eine Lebenszeit von fünf Jahren für ein Hauptrelease fest. Wie die Windows-Varianten von PostgreSQL 8.0 und 8.1 zeigen, kann diese für einzelne Plattformen jedoch auch verkürzt sein. Eine Auflistung der Release Policy kann über das Entwickler-Wiki des PostgreSQL-Projektes eingesehen werden.

Noch ist PostgreSQL 9.0 nicht fertig, doch Hot Standby kann mit der Alphaversion 8.5alpha3 bereits getestet werden. Die aktuelle Alphaversion wurde übrigens noch nach dem 8.5 Entwicklerzweig benannt, bevor die Entscheidung für den Schritt zu Version 9.0 fiel. Mit der 9.0alpha4-Version kann Ende Februar gerechnet werden, diese wird dann auch Streaming Replication enthalten. Interessierte legen wir den Leitfaden "How To Beta Test" ans Herz, der einige Richtlinien für Tests oder Feedback definiert.