PostgreSQL-Administration E-Book

Peter Eisentraut

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2013

Seitenzahl: 632

Beschreibung

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.

Leseprobe

PostgreSQL-Administration

Peter & Eisentraut

Vorwort

Das fortschrittlichste Open-Source-Datenbankmanagementsystem der Welt, so lautet weithin unangefochten seit über einem Jahrzehnt der Untertitel zu PostgreSQL. Mittlerweile ist es millionenfach im Einsatz, als Teil der kritischen öffentlichen Infrastruktur des Internets und der Gesellschaft und als zentrales Element in der Zukunft der Datenbankwelt.

Doch jeder kann Teil dieser Erfolgsgeschichte sein. PostgreSQL ist Open Source, es ist kostenlos verfügbar und wird von einer großen, offenen Community von Anwendern und Entwicklern vorangetrieben. Dieses Buch möchte seinen Teil dazu beitragen, dieses Software-Produkt allen interessierten Anwendern zugänglich zu machen.

Zielgruppe

Dieses Buch richtet sich primär an Administratoren von PostgreSQL-Datenbanksystemen. Es soll dabei helfen, PostgreSQL-Datenbanksysteme erfolgreich, stabil und performant zu betreiben. Es wird davon ausgegangen, dass der Leser entweder schon Umgang mit PostgreSQL hatte oder über Erfahrungen mit der Administration von anderen Datenbanksystemen verfügt. Vertrautheit mit SQL und Unix-Shells wird von Vorteil sein.

Die Entwicklung von Datenbankanwendungen wird in diesem Buch nicht behandelt und fortgeschrittene Programmierkenntnisse sind auch nicht vonnöten. Allerdings wird im Zuge der Administration eines Datenbanksystems oft die Kommunikation zwischen Administration und Entwicklung notwendig sein. Daher sind Kenntnisse in Sachen Anwendungsentwicklung generell von Vorteil.

Dieses Buch soll die PostgreSQL-Dokumentation um praktische Erfahrungswerte ergänzen. Es kann aber dem PostgreSQL-Administrator im Alltag auch schon für sich genommen als eigenständige Referenz nützlich sein, wobei dieses Buch aber niemals den Anspruch haben kann, den gesamten Umfang des PostgreSQL-Systems abzudecken.

Struktur dieses Buchs

Dieses Buch besteht aus zehn Kapiteln. Die Kapitel sind so ausgelegt, dass sie der Reihenfolge entsprechen, in der man sich mit den entsprechenden Themen im Laufe des Lebens eines Datenbanksystems ungefähr befassen wird. Wer also schnell »von 0 auf 100« kommen möchte, kann dieses Buch von vorne bis hinten durchlesen. Jedes Kapitel soll aber auch für sich stehen und Anwendern, die schon einen gewissen Kenntnis- und Erfahrungsstand haben, die Möglichkeit geben, sich in bestimmten Themenbereichen weiterzubilden. Auf diese Weise kann das Buch außerdem als tägliche Referenz verwendet werden. Es ist also auch möglich – und in vielen Fällen wohl auch empfehlenswert –, das Buch in einer selbst gewählten Reihenfolge durchzuarbeiten.

Kapitel 1

Das Leben jeder Software beginnt mit der Installation.

Kapitel 2

Hier werden die Einstellungen der Konfigurationsparameter im PostgreSQL-Server erläutert.

Kapitel 3

Hier werden wiederkehrende Aufgaben beschrieben, die zur Wartung eines PostgreSQL-Servers notwendig sind.

Kapitel 4

Teil der Wartungsaufgaben ist die Datensicherung, der ein eigenes Kapitel gewidmet ist.

Kapitel 5

Hier werden Verfahren vorgestellt, mit denen Zustand und Verhalten eines PostgreSQL-Servers überwacht und analysiert werden können.

Kapitel 6

Hier wird beschrieben, was man tun kann, wenn irgendetwas beschädigt worden zu sein scheint.

Kapitel 7

Die Absicherung der Daten vor unberechtigtem Zugriff ist Thema dieses Kapitels.

Kapitel 8

Hier wird erläutert, wie man SQL-Befehle schneller machen kann.

Kapitel 9

Hier werden verschiedene Lösungen vorgestellt, um PostgreSQL-Datenbanken zu replizieren und zu clustern, um bessere Verfügbarkeit oder bessere Leistung zu erzielen.

Kapitel 10

Enthält Hinweise zu Auswahl und Einrichtung von Hardware für PostgreSQL-Systeme. Von der Logik her würde die Hardware-Auswahl wohl noch vor der Installation stattfinden, aber es ist auch sinnvoll, sich diesen Fragen erst dann zu widmen, wenn man die Interna eines PostgreSQL-Systems gut verstanden hat.

In diesem Buch behandelte Versionen

Dieses Buch behandelt hauptsächlich PostgreSQL 9.2 und 9.1. Die aktuellste PostgreSQL-Version zum Zeitpunkt der Drucklegung ist 9.2.2, aber alle Releases der Reihe 9.2 unterscheiden sich – wenn überhaupt – nur geringfügig bezüglich der Benutzerschnittstellen und der Verhaltensweise.

Wo es bedeutende Unterschiede gibt, wird auch kurz auf Version 9.0 und ältere Versionen eingegangen. Aber gerade bei der Datenbankadministration hat sich sowohl hinsichtlich der Möglichkeiten als auch bezüglich der Anforderungen über die letzten Jahre hinweg Hauptversionen sehr viel getan, weswegen ältere Versionen erstens aus Platzgründen nur kurz behandelt werden können und zweitens weniger zu empfehlen sind, wenn man die maximalen Möglichkeiten bei der Datenbankadministration ausnutzen möchte.

An den Stellen, an denen es um Betriebssystemeinstellungen und die Einbindung externer Programmpakete geht, haben wir natürlich eine Auswahl treffen müssen, die sich letztlich daran orientiert, womit wir selbst arbeiten und was wir weiterempfehlen wollen. Die allermeisten Teile dieses Buches gelten aber völlig unabhängig von der Wahl des Betriebssystems oder der Zusatzwerkzeuge.

Neues in der dritten Auflage

In der dritten Auflage wurden alle Kapitel dieses Buches überarbeitet und an neuere Software-Versionen und Hardware-Entwicklungen angepasst sowie um zusätzliche Erfahrungswerte erweitert. Wichtige Neuerungen gibt es insbesondere in den Bereichen Replikation, Überwachung sowie Performance-Optimierung.

Typografische Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursivschrift

Wird für die Namen von Programmen, Befehlen, Dateien, Verzeichnissen sowie für URLs verwendet.

Nichtproportionalschrift

Wird für SQL-Anweisungen sowie Codeteile, Codebeispiele und Systemausgaben verwendet.

Nichtproportionalschrift kursiv

Wird in Codebeispielen für Platzhalter verwendet, für die eigene Werte eingesetzt werden müssen.

Tipp

Dieses Symbol kennzeichnet einen Hinweis, der eine nützliche Anmerkung zum nebenstehenden Text enthält.

Warnung

Dieses Symbol kennzeichnet eine Warnung, die sich auf den nebenstehenden Text bezieht.

Danksagungen

Treibende Kraft bei diesem Buch war wieder einmal unser Lektor Volker Bombien. Seine Geduld und Ausdauer waren unbezahlbar.

Wir danken dem Fachlektor Sven Riedel und allen Kollegen, Probelesern und Vorabkritikern für ihre Hinweise.

Die credativ GmbH hat es uns ermöglicht, unser Hobby zum Beruf zu machen. Unseren Erfahrungsschatz, den wir in diesem Buch teilen möchten, konnten wir nur so aufbauen.

Wir grüßen das Linuxhotel und alle Schulungsteilnehmer, die gewissermaßen unsere Versuchskaninchen und Betatester beim Aufbau dieses Materials waren.

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

apt-get install postgresql

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.