Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

database:postgresql

PostgreSQL

Wir bieten PostgreSQL erst seit kurzem an und sind noch dabei Erfahrungen damit zu sammeln. Das gilt auch für unser hier beschriebenes Setup, das eventuell noch die eine oder andere Verbesserung braucht. In unseren Tests läuft es zwar bereits stabil, aber das heißt nicht, dass nicht noch irgendwo Fehler lauern. An Feedback sind wir daher sehr interessiert.

Umgangssprachlich ausgedrückt: Diese Anleitung ist Beta.

PostgreSQL ist ein freies, objektrelationales Datenbankmanagementsystem, das von vielen als hervorragende Alternative zu MySQL geschätzt wird. Bei Uberspace betreiben wir keine zentrale PostgreSQL-Instanz für alle User (wie wir es im Gegensatz dazu mit MySQL tun), vor allem deswegen weil sich das nicht gut mit unserem Quota-Management verträgt. User konnten sich aber schon immer eigene PostgreSQL-Instanz aufsetzen und einrichten und nachdem wir lange geprüft und überlegt haben, ob wir nicht doch eine zentrale PostgreSQL-Instanz bereitstellen sollten, haben wir uns dafür entschieden, statt dessen das Betreiben einer eigenen PostgreSQL-Instanz so einfach wie möglich zu machen.

Setup

Wir empfehlen ein Setup, bei dem Du Deine eigene PostgreSQL-Instanz unter den daemontools betreibst. So hast Du die volle Kontrolle und kannst auch jederzeit problemlos Plugins installieren, ohne dass andere User davon betroffen sind – bist aber auch selber für die Sicherheit der PostgreSQL-Instanz und Backups verantwortlich.

Damit Du Dir ganz leicht eine eigene PostgreSQL-Instanz einrichten kannst, haben wir ein Skript dafür geschrieben, das Du einfach per SSH auf der Shell ausführen kannst:

uberspace-setup-postgresql

Anschließend solltest Du Dich einmal ausloggen und wieder einloggen, damit alle Umgebungsvariablen sauber gesetzt werden und Du richtig mit Deiner PostgreSQL-Instanz arbeiten kannst.

Das wichtigste in Kürze

Und dann kann's auch schon losgehen. Damit Du Dich zurecht findest, hier ein paar Hinweise:

  • Wir konfigurieren PostgreSQL mit unserem Skript so, dass es nur ein Unix Domain Socket anlegt, aber nicht am Netzwerk lauscht, auch nicht am Loopback Interface.
  • Das Unix Domain Socket legen wir nach $HOME/tmp/ und damit PostgreSQL-Clients das dort auch finden, setzen wir die Umgebungsvariable $PGHOST entsprechend. Dadurch kannst Du Tools wie psql einfach so aufrufen und benötigst nicht den -h Parameter.
  • Es wird bei der Einrichtung ein Superuser angelegt, der genau so heißt wie Dein Useraccount. Wir vergeben für diesen User ein sehr langes und daher hoffentlich sicheres Passwort. Dieses Passwort findest du in der Datei ~/.pgpass. Falls Du es ändern möchtest, dann musst Du das zuerst in PostgreSQL selbst tun, eine Änderung des Passwortes in der ~/.pgpass selbst bringt nichts, außer dass Du Dich damit im ungünstigsten Fall aus Deiner PostgreSQL-Instanz aussperrst, ändere den Eintrag in der ~/.pgpass erst nachdem Du das Passwort in PostgreSQL selbst geändert hast und getestet hast, ob es funktioniert.
  • Es sind noch keine weiteren Datenbanken oder User angelegt. Wir empfehlen Dir dringend nicht den Superuser-Account für alltäglichen Zugriff auf die Datenbank zu verwenden, schon gar nicht für den Zugriff durch Applikationen, sondern hierfür extra User und extra Datenbanken in Deiner PostgreSQL-Instanz einzurichten. Datenbanken und User kannst Du mit Tools wie createdb und createuser anlegen, oder natürlich auch auf der PostgreSQL-Kommandozeile oder mit einem entsprechenden Frontend wie z.B. Adminer.

Wenn Du Programmen Zugang zu PostgreSQL verschaffen willst, dann leg am besten einen extra User nur für dieses Programm an und gib dem auch nur so viele Rechte wie das Programm benötigt. Damit das Programm sich dann mit Deiner PostgreSQL-Instanz verbinden kann müsstest Du ihm normalerweise vier Dinge mitteilen:

  1. den Server den es kontaktieren soll (FQDN oder IP-Adresse)
  2. den Port auf dem der Server lauscht
  3. einen validen Usernamen
  4. das Passwort dieses Users

Da Du in unserem Setup den Server aber nicht über die Kombination aus Name (oder IP-Adresse) und Port ansprechen kannst, sondern nur über das Unix Domain Socket, brauchst Du den Port überhaupt nicht anzugeben (oder wenn das nicht geht, gib den Standardport an) und beim Server gibst Du einfach den Pfad zum Unix Domain Socket an (klingt komisch, aber alle Programme die gegen die libpg linken verstehen das). Wenn Dein Account also z.B. nicole heißt, dann bräuchtest Du nicht localhost oder 127.0.0.1 als Server anzugeben, sondern /home/nicole/tmp/, wenn Dein Account matthias heißt wäre es /home/matthias/tmp/ usw.

PostgreSQL und die daemontools

Beim Betrieb von PostgreSQL unter den daemontools gibt es ein paar Dinge zu beachten:
  • PostgreSQL wird auf ein svc -d ~/service/postgresql (was ein SIGTERM schickt und anschließend ein SIGCONT) nicht damit reagieren, dass es sich zügig beendet, sondern es wird warten bis sich auch der letzte Client von ihm getrennt hat. Dies ist sozusagen der sanfte Shutdown. Das kann quasi unendlich lange dauern und ist in aller Regel nicht das, was man will.
  • Auf ein svc -i ~/service/postgresql (was ein SIGINT schickt) hin wird PostgreSQL alle Clients trennen und sich dann beenden. Dies ist der energische, aber saubere Shutdown.
  • PostgreSQL reagiert auch auf SIGQUIT (nämlich mit einem unsauberen Shutdown), dieses Signal kannst Du ihm mit den daemontools aber nicht schicken.
  • Verwende niemals svc -k ~/service/postgresql und beende PostgreSQL auch sonst nicht über ein SIGKILL, das kann zu Datenverlust führen.

PostgreSQL Version

Damit bei Updates nichts schief geht, legen wir PostgreSQL ähnlich wie wir es bei PHP machen auf ein bestimmtes Minor-Release fest (z.B. auf 9.3) und zwar mit der Datei ~/etc/postgresversion. Wenn wir dann Updates für dieses Release bereitstellen (also z.B. neben der 9.2.4 eine 9.2.5) dann kannst Du Deine PostgreSQL-Instanz einfach neustarten und schon erfolgt das Update. Dabei sollte Dein Setup nicht kaputt gehen, da Änderungen an dritter Stelle der Versionsnummer eigentlich nur Bugfixes enthalten. (Du kannst Deine PostgreSQL-Instanz über die ~/etc/postgresversion auf auf ein noch genaueres Release festlegen, dann gibt es gar keine Updates mehr ohne Dein Zutun.)

Wenn Änderungen im Minor oder gar im Major Release anstehen (also z.B. PostgreSQL 9.4 oder 10.0 erscheint), dann ändert sich die Version Deiner PostgreSQL-Instanz in unserem Setup nicht. Um so ein Update mitzunehmen, müsstest Du selbst aktiv eingreifen, indem Du die Version in der ~/etc/postgresversion umstellst und Deine PostgreSQL-Instanz neu startest. Bevor Du das tust, solltest Du Dir die Release Notes der jeweiligen PostgreSQL-Version anschauen, denn bei solchen Versionssprüngen gibt es Dinge zu beachten und es sind oft administrative Eingriffe nötig.

Netzwerkanbindung

PostgreSQL ist ähnlich wie MySQL in der Lage über das Netzwerk zu kommunizieren. Normalerweise geschieht dies über das Loopback-Interface, weil alles andere ohne TLS zu unsicher und gefährlich wäre. In unserem Setup schalten wir den Netzwerkzugriff für PostgreSQL allerdings erstmal komplett ab und zwar in erster Linie deswegen weil wir Dir ein PostgreSQL bereitstellen wollen, an dem wir möglichst wenig gemacht haben und Du nicht viel beachten musst bevor Du loslegen kannst – würden wir den Netzwerkzugriff an lassen, müssten wir ihn absichern, User anlegen, Passwörter setzen… wenn das dann am Ende nicht zu dem passt was Du mit PostgreSQL machen möchtest, dann müsstest Du das erst alles wieder ändern.

Du kannst den Netzwerkzugriff für PostgreSQL aber jederzeit wieder aktivieren:

  1. Zuerst lege User an, vergib Passwörter und ändere die ~/postgresql/pg_hba.conf um diesen Usern (und zwar nur nachdem sie ein valides Passwort genannt haben) den Zugriff auf PostgreSQL zu gewähren.
  2. Dann ändere in der Datei ~/postgresql/postgresql.conf die Zeile #listen_addresses = '' in listen_addresses = 'localhost'.
  3. Dann entferne in der Datei ~/postgresql/postgresql.conf in der Zeile mit #port = 5432 vorne das # und ändere die Portnummer. (Weil der Default-Port mit an Sicherheit grenzender Wahrscheinlichkeit schon von einer PostgreSQL-Instanz belegt sein wird, bei der jemand die Portnummer trotz dieses Hinweises nicht geändert hat.)
  4. Starte PostgreSQL zum Abschluss neu, damit es die Config-Änderungen übernimmt.
Achtung: Wenn Du die Portnummer änderst, ändert sich der Name des Unix Domain Sockets (darin kommt die Portnummer nämlich vor). Programme die weiterhin über das Unix Domain Socket zugreifen, benötigen daher die neue Portnummer, auch wenn sie gar nicht über den Port gehen, sondern weiter über das Unix Domain Socket. Analog zur Umgebungsvariable $PGHOST gibt es dafür auch die Umgebungsvariable $PGPORT, die Du dir in ~/.bashrc eintragen kannst.
Vorsicht: Binde PostgreSQL nur an das Loopback-Interface, nicht an eine öffentliche IP-Adresse! Falls Du über einen SSH-Tunnel von außen zugreifen möchtest, genügt es PostgreSQL an das Loopback-Interface zu binden. Es an eine öffentliche IP-Adresse zu binden bringt nur etwas, wenn Du Dir von uns einen Port öffnen lässt. Das können wir aber nicht empfehlen, außer vielleicht wenn Du auch TLS konfigurierst, damit der Zugriff über das Internet nicht ohne Verschlüsselung erfolgt.

Verschieben des Unix Domain Socket

Du kannst das Unix Domain Socket Deiner PostgreSQL-Instanz auch woanders ablegen als in /$HOME/tmp, wenn Du das möchtest, dazu musst Du die ~/postgresql/postgresql.conf ändern und dann Deine PostgreSQL-Instanz neustarten. Außerdem solltest Du einen einsprechenden Eintrag in Deiner ~/.bashrc vornehmen und so den von uns vordefinierten Wert von $PGHOST überschreiben, z.B.:

export PGHOST=/home/nicole/sockets

Schließlich solltest Du auch noch die Pfadangabe in Deiner ~/.pgpass anpassen.

Backup

Für den Fall der Fälle ist es immer gut ein Backup zu haben. Deswegen haben wir direkt ein Skript geschrieben, mit dem Du Dir eines einrichten kannst. Dazu musst Du es nur auf der Shell aufrufen:

uberspace-setup-postgresql-backup

Dieses Skript richtet Dir einen runwhen-Job ein, der einmal am Tag (zu einer bei der Installation zufällig ausgewählten, vollen Stunde – kannst Du natürlich ändern) ein weiteres Skript von uns ausführt: uberspace-postgresql-backup. Dieses wiederum führt pg_dumpall aus, schreibt dessen Ausgabe nach ~/postgresql-backup/ und zu Guter Letzt rotiert es die Backups. Von Hause aus werden erstmal 7 Backups vorgehalten (das kannst Du aber im run-Skript anpassen). Die Backups in ~/postgresql-backup/ fließen auch in unsere Backups des gesamten Hosts ein. Du findest also ein paar Backups dort und unter /backup/*/home/$USER/postgresql-backup/immer noch wesentlich mehr alte Kopien dieser Backups, 7 Tage sollten also mehr als genug sein.

Analog zu den MySQL-Backups werden die Backups mit dem Kompressionsprogramm xz ein bißchen komprimiert.

Frontends

adminer

Adminer ist ein hervorragendes Frontend zum Datenbankmanagement, das wir sehr empfehlen können. Um Adminer mit PostgreSQL zu nutzen müsstest Du Dir allerdings ein eigenes Adminer installieren und kannst nicht unser zentral bereitgestelltes Adminer nutzen, denn dieses könnte nur mit Deiner Postgres-Instanz kommunizieren wenn diese an localhost lauscht, was in unserem Default-Setup nicht der Fall ist.

phpPgAdmin

Statt Adminer könntest Du Dir bestimmt auch phpPgAdmin installieren. Das haben wir uns aber noch nicht näher angeschaut.

Nutzung mit Ruby

Möchtest du PostgreSQL mit Ruby ansprechen, beachte bitte unsere Hinweise zur Installation des pg-Gems.

database/postgresql.txt · Zuletzt geändert: 2016/01/21 14:58 von uber