PostgreSQL-Administration

Peter Eisentraut, Bernd Helmle

• Publisher: O'Reilly
• Year: 2013
• eBook ISBN: 9783955611590
• Edition: 3
• Topic: Computer Science
• Subtopic: Databases
• Index: Computer Science

PostgreSQL hat sich bei professionellen Datenbankadministratoren als hoch performantes und robustes Datenbanksystem durchgesetzt. PostgreSQL ist freie Software, wird seit Ende der 80er Jahre von einer engagierten Community ständig weiterentwickelt und besitzt die Eigenschaften, Zuverlässigkeit und Performance kommerzieller Datenbanksysteme. Die Autoren sind aktive Entwicklungsmitglieder der PostgreSQL Community und geschätzte Datenbankexperten. Die 3. Auflage von PostgreSQL Administration behandelt die im September 2012 erschienene Version 9.2. Die neue Version enthält gerade im Bereich Replikation, Konfiguration und Performance viele Verbesserungen.

Kapitel 1. Installation

In diesem Kapitel wird die Installation der PostgreSQL-Software beschrieben . Geübten und erfahrenen Administratoren mit den geeigneten Werkzeugen geht die Installation eines PostgreSQL-Servers leicht von der Hand. Ein Großteil des Vorgangs ist automatisiert.

Softwareinstallation

Der erste Schritt, um ein PostgreSQL-System einzurichten, besteht in der Installation der Software. In den meisten Situationen bieten sich dem Administrator zwei Varianten, wie diese durchgeführt werden kann: Entweder man baut die Software aus dem Quellcode selbst, oder man installiert ein vorgefertigtes Paket .

Das PostgreSQL-Projekt (also die Entwickler der Software) veröffentlicht zunächst nur den Quellcode . Die Pakete werden daraufhin von oder in Zusammenarbeit mit den Anbietern der verschiedenen Betriebssysteme zusammengestellt, um die Installation der Software auf dem jeweiligen System zu vereinfachen und sicherzustellen, dass die Software mit dem System gut zusammenarbeitet .

Was wir hier verkürzt als »Paket« bezeichnen, heißt auf verschiedenen Systemen unterschiedlich: Auf vielen Linux-Systemen wird es als RPM oder Debian-Paket bezeichnet, auf BSD-Systemen entweder als Port oder als Package , auf Mac OS X finden sich MacPorts und Homebrew, und für Windows gibt es einen Installer .

Zu der Frage, welche Installationsart zu wählen ist, gibt es viele Meinungen. Ausschlaggebend sind dabei folgende Aspekte:

• Ist die gewünschte Version verfügbar?
• Ist absehbar, dass zukünftige Versionen rechtzeitig verfügbar sein werden?
• Wie ist die Qualität der Paketierung?
• Bestehen Sonderwünsche, die die Paketierung nicht erfüllt?
• Womit ist der Administrator am besten vertraut?

Wer hingegen den Quellcode selbst bauen und installieren will, sieht sich mit vielen zusätzlichen Aufgaben konfrontiert:

• Compiler pools müssen bereitgestellt werden.
• Abhängigkeiten müssen selbst verwaltet werden.
• Benutzer und Dateisystemrechte müssen eingestellt werden.
• Startskripten müssen geschrieben und konfiguriert werden.
• Logging, Wartung, Datensicherung und Ähnliches müssen erledigt werden.

Für diejenigen Betriebssysteme, die mit PostgreSQL am häufigsten eingesetzt werden, sieht die Situation so aus, dass sich der Einsatz einer paketierten Variante auf jeden Fall lohnt.

Versionierung

Bevor man die Einrichtung eines PostgreSQL-Systems angeht, sollte man sich klarmachen, welche Versionen es gibt und welche von ihnen man verwenden möchte.

PostgreSQL verwendet eine dreiteilige Versionsnummer , zum Beispiel 8.4.10 oder 9.2.0. Die erste Ziffer der Versionsnummer ändert sich nur sehr selten, nämlich dann, wenn eine neue »Ära« im Projekt anbricht. Die zweite Ziffer ändert sich, wenn ein neues großes Release mit neuen Features ausgeliefert wird. Die dritte Ziffer der Versionsnummer ändert sich mit jedem kleinen Release, das nur kritische Fehler berichtigt.

Dieses Versionsnummernschema ist aus technischer Sicht etwas unpassend, denn die erste und die zweite Zahl bilden im Prinzip eine Einheit. Aus Sicht der Entwickler gibt es einen großen Releasezweig »9.2« mit den Unterversionen 9.2.0, 9.2.1 und so weiter, je nachdem, wie oft Fehlerkorrekturen in dem Zweig notwendig werden. Insofern sind etwa 8.4 oder 9.2 als »Hauptversionsnummern« (major version) anzusehen, denn immer wenn sich die zweite Ziffer der Versionsnummer ändert (und eventuell auch die erste), enthält die neue Version neue Features. Wir verwenden den Begriff »Hauptversion« in diesem Buch in diesem Sinn. Die einzelne erste Ziffer (8 oder 9) hat eher repräsentativen Charakter, aber keine technischen Auswirkungen – die Unterschiede zwischen 8.4 und 9.0 sind vom Prinzip her nicht anders als die zwischen 8.3 und 8.4 oder die zwischen 9.0, 9.1 und 9.2. Es ist daher in jedem Fall falsch und sinnlos, etwa von einer Version »PostgreSQL 9« zu sprechen. (Das ist ähnlich wie beim Linux-Kernel. Auch da ist die Bezeichnung »Linux 2« oder »Linux 3« unsinnig.)

In der Praxis wird etwa einmal im Jahr eine neue Hauptversion herausgebracht. Es gibt dazu, wie bei Open Source-Projekten üblich, keinen lange voraus erdachten Releaseplan, aber dieser Zyklus hat sich über viele Jahre eingependelt. Man kann also, solange es in Zukunft keine gegenteiligen Bekanntmachungen gibt, davon ausgehen, dass es in etwa so weitergehen wird.

Eine Hauptversion bildet einen Zweig in der Entwicklung, der dann noch mehrere Jahre gewartet wird. Das heißt, es werden noch Fehlerkorrekturen eingespielt und etwa Übersetzungen verbessert und aktualisierte Zeitzonenregeln eingebaut, aber keine neuen Features mehr entwickelt. Dies wird auch fortgesetzt, nachdem die nächste Hauptversion veröffentlicht wurde. Es gibt also immer mehrere gepflegte Hauptversionen. Der Wartungszeitraum einer Hauptversion beträgt aktuell fünf Jahre ab Veröffentlichung der Version x.y.0. Einzelheiten dazu sowie eventuelle Abweichungen werden unter anderem über die Website des PostgreSQL-Projekts veröffentlicht. Es wird davon ausgegangen, dass man in diesem Zeitraum die Möglichkeit findet, den Umstieg auf eine neuere Hauptversion anzugehen. Die Spanne von fünf Jahren deckt sich auch ungefähr mit den Supportzeiträumen von Linux-Distributionen der »Enterprise«- oder »Long-Term-Support«-Klasse.

Wenn Anwender oder Entwickler neue Projekte angehen, die auf PostgreSQL aufsetzen, ist ihnen prinzipiell zu empfehlen, die neueste Hauptversion einzusetzen. Das gilt auch, wenn diese zum Beispiel bei Projektstart erst kurz vor der Veröffentlichung stehen. Eine neue Version hat immer mehr Features und eine besse...

Table of contents

• Cover
• Titel
• Inhalt
• Vorwort
• 1. Installation
• 2. Konfiguration
• 3. Wartung
• 4. Datensicherung
• 5. Überwachung
• 6. Wiederherstellung, Reparatur und Vorsorge
• 7. Sicherheit, Rechteverwaltung, Authentifizierung
• 8. Performance-Tuning
• 9. Replikation und Hochverfügbarkeit
• 10. Hardware
• Index
• Kolophon
• Impressum