WAL-Shipping
In der KW 49 wurde ein neues Backup/Failover System zur Sicherung von Postgresql Datenbanken getestet, genannt WAL-Shipping. WAL (Write Ahead Log) ist ein Verfahren der Datenbanktechnologie, das zur Gewährleistung der Atomarität und Dauerhaftigkeit von Transaktionen beiträgt.
Durch das WAL-Prinzip wird ein sogenanntes „Update-in-Place“ ermöglicht, d.h. die alte Version eines Datensatzes wird durch die neue Version an gleicher Stelle überschrieben. Das hat vor allem den Vorteil, dass Indexstrukturen bei Änderungsoperationen nicht mit aktualisiert werden müssen, weil die geänderten Datensätze immer noch an der gleichen Stelle zu finden sind. Die vorherige Protokollierung einer Änderung ist erforderlich, um im Fehlerfall die Wiederholbarkeit der Änderung sicherstellen zu können.
Der WAL-Manger tut nun im Prinzip nichts anderes, als die Protokolldateien (WAL-Files) vom primären Datenbanksystem (Master) mit einem sekundären Datenbanksystem (Slave) zu synchronisieren.
Das sekundäre Datenbanksystem „wartet“ auf neue WAL-Files, um diese live einpflegen zu können. In dieser Zeit muss die sekundäre Datenbank in einem „Restore“ Modus laufen und kann/darf während dieser Zeit nicht aktiv als Datenbanksystem verwendet werden. Der WAL-Manager an sich ist ein in Phyton geschriebenes Script, welches die WAL-Logs aus der Master Datenbank abholt und diese auf der Gegenseiten (dem Slave) wieder in die Datenbank einspielt. Diese WAL-Files sind Binär-Dateien, somit ist leider keine „Live-Kontrolle“ der synchronisierten Daten möglich.
In der Praxis verliefen unsere Tests leider nicht ganz so rosig, wie es der WAL-Manager verspricht. Das Synchronisieren größerer Datenmengen dauert teilweise sehr lange (für 10GB große Änderungen in der Datenbank ca. 20-25 Minuten anhand der rsync Laufzeit). Leider mussten wir feststellen, dass auch nach über 1 Stunde die Datenbank nicht vollständig synchronisiert war. Der WAL-Manger hält zwar sein Versprechen, konsistente Datensätze zu gewährleisten; allerdings auf die ganze Datenbank gesehen (Anzahl der Datensätze), treten teilweise sehr große Inkonsistenzen auf. Das bedeutet konkret: Jeder einzelne Datensatz ist für sich konsistent, die Vollständigkeit aller Datensätze in den Tabellen konnte aber nicht gewährleistet werden. Diese zeichneten sich dadurch aus, das „manche“ Datensätze zwar vorhanden waren, „manche“ aber auch nicht. Die geänderten Datensätze waren nach dem „Zufallsprinzip“ in der sekundäre Datenbank wieder zu finden. Dies hat zur Folge, dass wir keine konkrete Aussage machen können, bis zu welchem Zeitraum wir die Daten noch vollständig haben und welche fehlen.
Zusammenfassend: Die Synchronisation dauerte zu lange und der Datenbank als ganzes drohte im Fehlerfall Inkonsistenz. Das bedeut für uns: Als Backup-Lösung für die SOSPOS-Datenbank ungeeignet.