PostgeSQL
Seit PostgreSQL 8.5 gibt es eine eingebaute Replikation (Streaming Replication: WAL-Shipping).
Veröffentlichungen
Postgresql 9.1 mit synchroner Replikation
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.
PostgreSQL 9.0 Beta mit eingebauter Replikation
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)
Betaversion von PostgreSQL 9.0 veröffentlicht
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.
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.
Beschreibung
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 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.
PostgeSQL 8.1 (ArchLinux)
grundsätzliches
# vi ~postgres/data/postgresql.conf
# vi ~pgsql/data/postgresql.conf
listen_addresses = '*'
port = 5432
max_connections = 100
ssl = off
shared_buffers = 1000
log_directory = '/var/log'
log_filename = 'postgresql.log'
log_rotation_size = 10240
stats_start_collector = on
stats_row_level = on
autovacuum = on
timezone = MET
client_encoding = UTF-8
lc_messages = 'de_DE.utf8'
lc_monetary = 'de_DE.utf8'
lc_numeric = 'de_DE.utf8'
lc_time = 'de_DE.utf8'
# vi ~postgres/data/pg_hba.conf
# vi ~pgsql/data/pg_hba.conf
# IPv4 local connections:
host all all 127.0.0.1/32 trust
host all all 192.168.4.111/32 trust
host all all 192.168.4.112/32 trust
# vi ~postgres/data/pg_ident.conf
# vi ~pgsql/data/pg_ident.conf
MAPNAME IDENT-USERNAME PG-USERNAME
SSL-Verschlüsselte Verbindungen
Der Server wartet auf normale und auf SSL-Verbindungen auf dem selben
TCP-Port und verhandelt mit verbindenden Clients ob SSL verwendet
werden soll.
SSL konfigurieren
# vi /etc/ssl/openssl.cnf
....
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering
....
[ req ]
default_bits = 8192
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
....
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = DE
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Hessen
localityName = Locality Name (eg, city)
localityName_default = Frankfurt am Main
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Interactive Data Managed Solutions
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = System Administration
commonName = Common Name
commonName_default = manfred.frankfurter-softwarefabrik.de
commonName_max = 64
emailAddress = eMail Adresse
emailAddress_default = manfred.heins@interactivedata.com
emailAddress_max = 64
....
selbstsigniertes Zertifikat erzeugen:
# cd ~postgres/data/
# cd ~pgsql/data/
### Bei "Common Name" muss der Hostname rein!
openssl req -new -text -out server.req
### Passphrase entfernen:
openssl rsa -in privkey.pem -out server.key && rm privkey.pem
### Schlüssel entsperren
openssl req -x509 -in server.req -text -key server.key -out server.crt
rm server.req
chmod og-rwx server.key
chown postgres:postgres server.*
chown pgsql:pgsql server.*
# vi ~postgres/data/postgresql.conf
# vi ~pgsql/data/postgresql.conf
....
ssl = on
....
# vi ~postgres/data/pg_hba.conf
# vi ~pgsql/data/pg_hba.conf
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
### damit nur noch SSL-verschlüsselte Verbindungen möglich sind
hostssl all all 127.0.0.1/32 trust
hostssl all all 192.168.4.111/32 trust
hostssl all all 192.168.4.112/32 trust
PostgeSQL 8.0 (Gentoo Linux)
# mkdir -p /home/postgresql/data # chown -R postgres:postgres /home/postgresql # rm -fr /var/lib/postgresql # ln -s /home/postgresql /var/lib/postgresql
# vi /etc/locale.gen
de_DE ISO-8859-1
de_DE@euro ISO-8859-15
de_DE.UTF-8 UTF-8
# locale-gen
#su -l postgres -c 'initdb -D /home/postgresql/data -E UNICODE --locale=de_DE.UTF-8' #su -l postgres -c 'initdb -D /home/postgresql/data -E UTF8 --locale=de_DE.UTF-8' #su -l postgres -c 'initdb -D /home/postgresql/data -E UTF-8 --locale=de_DE.UTF-8'
# su -l postgres -c 'initdb -D /home/postgresql/data --locale=de_DE.UTF-8'
oder
emerge postgresql --config
# vi /home/postgresql/data/postgresql.conf
listen_addresses = 'localhost'
port = 5432
max_connections = 1
ssl = off
shared_buffers = 1000 # min 16, at least max_connections*2, 8KB each
log_directory = '/var/log'
log_filename = 'postgresql.log'
log_rotation_size = 10240 # Automatic rotation of logfiles will happen after
stats_start_collector = true
stats_row_level = true
timezone = CET
#client_encoding = UTF8
client_encoding = UTF-8
lc_messages = 'de_DE.UTF-8' # locale for system error message strings
lc_monetary = 'de_DE.UTF-8' # locale for monetary formatting
lc_numeric = 'de_DE.UTF-8' # locale for number formatting
lc_time = 'de_DE.UTF-8' # locale for time formatting
# /etc/init.d/postgresql start
# cat /home/postgresql/backup/2008-01-14 | psql -h localhost -U postgres -d template1 # psql -h localhost -U postgres -l
Replikation
- 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)
