PostgreSQL Agenda 2010

| Keine Kommentare | Keine TrackBacks

PostgreSQL LogoPostgreSQL 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 9.0

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

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.

Streaming Replication - Eingebaute asynchrone Replikation

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.

Ein Abgesang auf PostgreSQL 7.4, 8.0 und 8.1

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.

Ausblick

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.

Keine TrackBacks

TrackBack URL: http://blog.credativ.com/cgi-bin/mt-tb.cgi/13

Kommentar hinterlassen