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 bessere Leistung, und mittelfristig wird man sowieso nicht um sie oder eine spätere Version herumkommen, wenn man PostgreSQL weiterhin einsetzen möchte.

Unterversionen (minor releases) werden etwa alle paar Monate herausgebracht, je nachdem, wie oft Korrekturen notwendig sind. Meist werden dabei Unterversionen von allen noch gewarteten Hauptversionen gleichzeitig herausgebracht, wenn die Fehlerkorrekturen auf alle zutreffen. Unterversionen sollten in der Regel umgehend von allen Anwendern eingespielt werden. Wer eine paketbasierte Installation hat, wird in der Regel entsprechende Updates automatisch erhalten.

Paketinstallation

Für einige populäre Linux-Betriebssysteme stellen wir hier kurz die Installation von PostgreSQL aus Binärpaketen vor.

Debian und Ubuntu

Das Debian-Paket für den PostgreSQL-Server heißt postgresql. Man installiert es also mit dem Befehl

Wenn man nur die Clientprogramme benötigt, installiert man das Paket postgresql-client. Das Serverpaket hängt vom Clientpaket ab, also ist es nicht notwendig, das Clientpaket zu installieren, wenn das Serverpaket schon installiert ist.

Debian und Ubuntu bieten die Möglichkeit, verschiedene Hauptversionen von PostgreSQL parallel zu installieren. Dazu besitzt jede Version eine eigene Paketgruppe. Die Pakete zu Version 9.1 heißen zum Beispiel postgresql-9.1 und postgresql-client-9.1. Die unversionierten Pakete postgresql und postgresql-client sind eigentlich leere Pakete, die nur Abhängigkeiten in Bezug auf die Pakete der jeweils aktuellen Version aufweisen.

Ein stabiles Release von Debian oder Ubuntu enthält in der Regel nur eine oder maximal zwei Hauptversionen von PostgreSQL. Der Sinn dahinter ist der, dass neue Anwender die neue PostgreSQL-Version verwenden, existierende Anwendungen aber nach einem Upgrade des Betriebssystems die alte Version weiterverwenden können. Wer sich an die stabilen Releases von Debian oder Ubuntu halten möchte, dem sei empfohlen, die jeweils mitgelieferten Versionen zu verwenden. Darüber hinaus sind aber meist auch Backports von neueren Versionen in den entsprechenden Backport-Repositories verfügbar.

Red Hat

Unter Red Hat Linux (sowie Fedora, die Bezeichnung wird in diesem Buch synonym verwendet) heißt das Paket für den PostgreSQL-Server postgresql-server. Man beachte, dass das Paket namens postgresql lediglich einige clientseitige Programme enthält und nicht das darstellt, was man normalerweise unter einer vollständigen PostgreSQL-Installation versteht. (Gelegentlich ist es natürlich sinnvoll, ausschließlich den Client zu installieren.)

Installieren kann man die gewünschten Pakete zum Beispiel mit Yum

oder mit einem grafischen Paketverwaltungsprogramm.

SUSE

Auch auf SUSE Linux (sowie openSUSE) heißt das Serverpaket postgresql-server und das Clientpaket postgresql. Zur Installation verwendet man am besten YaST, oder zypper von der Konsole. Neben den in den Distributionen mitgelieferten PostgreSQL-Paketen werden auf dem openSUSE Build Service oft Backports von neueren PostgreSQL-Versionen angeboten.

Quellcode...