PostgreSQL bietet aber auch die Möglichkeit im Betrieb ein sogenanntes Write-Ahead-Log (WAL), neben den eigentlichen Datenbestand, auf die Festplatte zu schreiben. Es enthält alle Aufzeichnungen sämtlicher im Datenbanksystem vorgenommenen Schreiboperationen. Falls das System ausfällt, können diese Aufzeichnungen verwendet werden, um die Datenbank wieder herzustellen. Es handelt sich hierbei um das gleiche Prinzip wie ein “Journal” von Linux Dateisystemen.

Eigentlich wird das Write-Ahead-Log in regelmäßigen Abständen mit dem Datenbestand abgeglichen und wieder gelöscht, da es nicht mehr benötigt wird. Es kann aber auch für eine Datensicherung verwendet werden. Die Aufzeichnungen bestehen aus Segmenten, je 16MB groß und im Verzeichnis pg_xlog zu finden.

Um eine Datensicherung mit WAL zu betreiben, braucht man als erstes eine Basissicherung. Hierfür kann ein einfaches Shellscript verwendet werden:

#!/bin/sh
 
set -e
filename=/data/wal_archive/basebackup_`hostname`_$(date +'%Y-%m-%dT%H%M%S.%N%z').tar.gz
psql -U postgres -c "SELECT pg_start_backup('$filename');" > /dev/null
tar --force-local -C /data -c -z -f "$filename" --anchored --exclude=pg_xlog pgsql || [$? -eq 2]
psql -U postgres -c "SELECT pg_stop_backup();" > /dev/null

Mit den PostgreSQL Befehlen pg\_start\_backup() und pg\_stop\_backup() kann das komplette Datenbanksystem gesichert werden. Das erzeugte Tarball wird unter /data/wal_archive gespeichert. Die PostgreSQL Installation wird unter /data/pgsql erwartet.

Nachdem die Basissicherung erstellt wurde, kann PostgreSQL für WAL konfiguriert werden. PostgreSQL selber macht hier keine Vorschriften, wie die WAL Segmente archiviert werden sollen, es können beliebige Shell Befehle aufgerufen werden. Man hat z.B. die Möglichkeit die Segmente einfach mit cp zu kopieren, könnte sie aber auch mit rsync auf einen anderen Rechner schieben. Die Konfiguration wird in der Datei postgresql.conf vorgenommen:

archive_mode = on
archive_command = 'test ! -f /data/wal_archive/%f && cp %p /data/wal_archive/%f'

Es ist hier wichtig, dass keine vorhandenen Dateien überschrieben werden, deshalb wird vor dem kopieren getestet, ob die entsprechende Datei schon vorhanden ist. Der Platzhalter %f ist der Dateiname für die Zieldatei, %p ist die zu kopierende Datei mit vollständigem Pfad.

Nachdem PostgreSQL neu gestartet wurde, werden die WAL Dateien, sofern 16MB Daten geschrieben wurden nach /data/wal_archive kopiert. Es ist nicht möglich, kleinere Datei zu schreiben, deswegen besteht das Risiko max. 16MB an Daten zu verlieren, wenn der Server stirbt und die WAL Datei noch nicht geschrieben hat. Es gibt allerdings die Möglichkeit einen Timeout zu setzen, nach welchem auf jeden Fall das Segment geschrieben werden soll.

archive_timeout = 60

Hierdurch würden alle 60 Sekunden ein Segment geschrieben werden, auch wenn keine Schreiboperation durchgeführt würde! Das Segment ist dann trotzdem 16MB groß, und mit NULL Daten gefüllt. Es ist also abzuwägen ob und wie hoch der Timeout sein soll.

Grundsätzlich sichere ich die WAL Segmente großer Datenbank auf einen anderen Server, damit das Hauptsystem nicht durch das Backup bzw. den erhöhten Speicherbedarf belastet wird. Einerseits kann das Segment auf ein mit NFS eingehängtes Volumen gespeichert werden, oder es wird mit scp oder rsync kopiert. Der archive_command Aufruf für rsync könnte wie folgt ausehen:

archive_command = 'rsync --delay-updates --whole-file -ar -e ssh %p postgres@192.168.0.2:/data/wal_archive/%f </dev/null'

Die Segmente werden dann automatisch in das Verzeichnis /data/wal_archive auf dem Server 192.168.0.2 kopiert. Es sollte allerdings ein SSH-Key ohne Passwort auf dem Zielsystem für den Benutzer postgres hinterlegt sein.

Für die eigentliche Sicherung muss nur nach das Verzeichnis /data/wal_archive auf dem Server 192.168.0.2 eingetragen werden. Zugegeben, diese Art von Datensicherung verbraucht viel Speicherplatz, da die Festplattenpreise allerdings sehr niedrig sind und das Datenbanksystem kaum belastet wird, rechtfertigt sich der hohe Speicherbedarf durchaus.

Die Skytools sind von Skype, und können auf der PgFoundry Seite gefunden werden. Als Beispiel nehmen wir eine einfache Datenbank mit nur einer Tabelle…

CREATE SEQUENCE test_seq START WITH 1;
CREATE TABLE test (
  id int4 PRIMARY KEY, 
  txt text
);

Jetzt brauchen wir noch ein paar Datensätze…

INSERT INTO test VALUES ((SELECT NEXTVAL('test_seq')), 'bla');
INSERT INTO test VALUES ((SELECT NEXTVAL('test_seq')), 'blub');
INSERT INTO test VALUES ((SELECT NEXTVAL('test_seq')), 'test text');

Nachdem alle Tabelle angelegt ist, sollte die Datenbank auf dem Slave Server erstellt werden. Danach können die Inhalte mit einem Dump initial übernommen werden…

$ pg_dump -U postgres -s test | psql -h <IP-VON-SLAVE> -U postgres test

Damit londiste laufen kann, brauchen wir einen Ticker, dieser muss auf dem Master-Server laufen. Die Konfiguration kann wie folgt aussehen (hier die Datei /etc/ticker.ini):

[pgqadm]
job_name = ticker
db = dbname=test 
maint_delay_min = 1
loop_delay = 0.5
logfile = /tmp/log.%(job_name)s
pidfile = /tmp/pid.%(job_name)s
use_skylog = 0
connection_lifetime = 21
queue_refresh_period = 10

Danach kann der Ticker gestartet werden…

$ pgqadm.py -d /etc/ticker.ini ticker

Als nächstes brauchen wir noch für londiste ebenfalls eine Konfigurationsdatei (hier /etc/londiste.ini):

[londiste]
job_name = test_to_subcriber
provider_db = dbname=test port=5432 host=<IP-VON-MASTER>
subscriber_db = dbname=test port=5432 host=<IP-VON-SLAVE>
pgq_queue_name = londiste.replika
logfile = /tmp/%(job_name)s.log
pidfile = /tmp/%(job_name)s.pid

Die londiste Konfigurationsdatei muss auf beiden Server sein, damit die Replikation funktioniert. Auf dem Slave-System kann londiste nun installiert werden

$ londiste.py /etc/londiste.ini provider install
$ londiste.py /etc/londiste.ini subscriber install
$ londiste.py /etc/londiste.ini provider add test
$ londiste.py /etc/londiste.ini subscriber add test
$ londiste.py -d /etc/londiste.ini replay

Londiste läuft nun im Hintergrund als Daemon und sollte alle neuen Daten sofort auf den Slave replizieren.

Seit PostgreSQL 8.3 ist tsearch2 direkt integriert. Bei tsearch2 handelt
es sich um eine Volltextsuche, welche direkt in PostgreSQL angesprochen wird.
Dadurch ist es möglich, die Informationen für die Suche direkt in die Tabellen einzubetten.

Tsearch2 liefert einige neue Datentypen und Funktionen, mit welchen gearbeitet werden
kann. Ein Datentyp ist z.B. tsvector, welchen man direkt testen kann…

SELECT 'Der erste String zum testen '::tsvector;
               tsvector                
---------------------------------------
 'Der' 'zum' 'erste' 'String' 'testen'
(1 ROW)

Als Ergebnis bekommen wir alle Wörter des Strings. Wörter, welche
doppelt im Text stehen, werden nur einmal angezeigt, was durchaus auch
Sinn macht.

SELECT 'Der erste String zum testen und testen '::tsvector;
               tsvector                   
---------------------------------------------
 'Der' 'und' 'zum' 'erste' 'String' 'testen'
(1 ROW)

Um das ganze mal etwas praktischer anzugehen, legen wir uns als erstes
eine Tabelle an, welche Texte enthalten soll:

CREATE TABLE messages (
	id int4,
	message text);

Und wir brauchen auch noch Inhalte…

INSERT INTO messages VALUES ('1', 'Dies ist eine Testnachricht');
INSERT INTO messages VALUES ('2', 'Dumdidum Nachricht');
INSERT INTO messages VALUES ('3', 'Ich bin ein Blindtext');

Jetzt haben wir ein Paar Daten in der Tabelle, aber noch keine Möglichkeit
einen Volltextindex zu speichern. Den Index können wir wie folgt anlegen:

ALTER TABLE messages ADD COLUMN idxFTI tsvector;

Um das Feld die neue Spalte initial zu füllen sollte man wie folgt vorgehen:

• Tabelle updaten
• vacuum full analyze ausführen
• Index erstellen
• nochmal vacuum full analyze ausführen

Als erstes erzeugen wir den Volltextindex aus der Spalte message und
führen ein Vacuum aus…

UPDATE messages SET idxFTI=to_tsvector('default',message);
VACUUM FULL ANALYZE;

Wenn z.B. mehrere Spalten in den Volltextindex aufgenommen werden sollen,
dann könnte man es wie folgt machen…

UPDATE messages
  SET idxFTI=to_tsvector('default',COALESCE(message,'') ||' '|| COALESCE(andereSpalte,''));
VACUUM FULL ANALYZE;

Jetzt erzeugen wir einen normalen Index auf der Spalte idxFTI…

CREATE INDEX idxFTI_idx ON messages USING gist(idxFTI);
VACUUM FULL ANALYZE;

Im Prinzip kann man schon jetzt per Volltext suchen. Eine Suche nach
dem Wort “ein” liefert z.B.

SELECT id, message FROM messages WHERE idxfti @@ 'ein'::tsquery;
    id |           message           
-------+-----------------------------
     1 | Dies ist eine Testnachricht
     3 | Ich bin ein Blindtext
(2 ROWS)

Wie aber erzeugen wir den Inhalt von idxFTI, wenn ein neuer
Datensatz eingetragen wird? Hier helfen Trigger und Stored Procedures…

CREATE OR REPLACE FUNCTION vectorupdate()
  RETURNS TRIGGER AS $vectorupdate$
BEGIN
  UPDATE messages
  SET idxFTI=to_tsvector('default',message) WHERE id=NEW.id;
 
  RETURN NEW;
END;
$vectorupdate$ LANGUAGE plpgsql;
 
CREATE TRIGGER tgr_vectorupdate AFTER INSERT OR UPDATE ON messages
  FOR EACH ROW EXECUTE PROCEDURE vectorupdate();

Wenn jetzt ein neuer Datensatz eingetragen bzw. verändert wird, dann
wir auch automatisch der Volltextindex aktualisiert.

Natürlich war dies nur ein kurzer Abriss von tsearch2, für den
vollen Einblick muss ich auf die
Dokumentation verweisen.