Serviceübernahme mit Slony-I Vorwort Slony-I ist ein asynchrones Replikationssystem, aus diesem Grund ist davon auszugehen dass in dem Moment wo der Ausgangspunkt eines bestimmten "Sets" ausfällt, noch nicht alle bestätigten Transaktionen auch auf alle Subscriber repliziert wurden. Das derartige System natürlich immer nur unter hoher Last und und zum ungünstigsten Zeitpunkt ausfallen ist leider Tatsache. Das wichtigste Ziel eines zuverlässigen Replikationssystems, sollte es daher sein den Hauptserver unter allen Umständen vorm Versagen zu bewahren, ereichen kann man dies vorallem durch regelmässige Wartung. Das Öffnen des Gehäuses eines laufenden Servers, fällt allerdings nicht unbedingt unter das was gemeinhin als "professionelle System- wartung" bezeichnet wird. Interessanterweise hat jedoch gerade die Anwendergruppe die sich für Replikations- und Backuplösungen interessiert, eine sehr geringe Toleranzschwelle für Begriffe wie "Ausfallszeiten". Um diese Anforderungen zu erfüllen, bietet Slony-I nicht nur Failover-Fähigkeiten sondern bietet auch Möglichkeiten für einen kontrollierten Master-Rollentransfer. In diesem Dokument wird in weiterer Folge davon ausgegangen das der Leser grundsätzlich mit dem "slonik" Kommandozeilentool vertraut ist und zumindest ein einfaches Replikationssystem mit zwei Knoten installieren kann. kontrollierte Serviceübernahme Es wird von einer aktuellen Datenquelle - Knoten 1 (Master) - mit einem entsprechenden Datenempfänger Knoten 2 (Slave) ausgegangen. Eine Webapplikation die auf einem dritten System läuft verwendet die Datenbank auf Knoten 1, beide Datenbanken sind aktiv und die Replikation ist weitestgehend syncron. Schritt 1) Zum Zeitpunkt der Erstellung dieses Dokuments erfordert eine kontrollierte Übernahme auf einen anderen Server einen erneuten Verbindungsaufbau der Applikation zur Datenbank. Um Komplikationen für die weiteren Schritte zu vermeiden wird daher einfach der Webserver deaktiviert. Anwender der Verbindungspoolingsoftware "pgpool" können auch einfach nur diese deaktivieren. Schritt 2) Ein kurzes "slonik" Skript führt die folgenden Kommandos aus: lock set (id = 1, origin = 1); wait for event (origin = 1, confirmed = 2); move set (id = 1, old origin = 1, new origin = 2); wait for event (origin = 1, confirmed = 2); Nach der Ausführung, ist nun die Datenquelle des Datensets 1 auf dem Knoten 2 zu finden. Es wurde nicht einfach nur transferiert, sondern die Übernahme erfolgte in einer Weise die sicherstellt, dass der Knoten 1 nun ein voll syncronisierter Empfänger, welcher aktiv die Daten repliziert, ist. Beide Knoten haben somit ihre Rollen komplett getauscht. Schritt 3) Nach der Rekonfiguration der Webapplikation (oder des "pgpool"-Daemons) um auf die Datenbank zu verbinden, die nun auf Knoten 2 läuft, sollte der Webserver neu gestartet werden. Ausgeführt mittels Hilfe eines Shellskriptes, welches dieses Herunterfahren, die Neukonfiguration mittels "slonik" sowie das Verschieben der Konfigurationsdaten sammt anschliessendem Neustart automatisch erledigt, dauert diese Prozedure weniger als zehn Sekunden. Danach ist es möglich, den Knoten 1 herunterzufahren und die nötigen Wartungsarbeiten vorzunehmen. Nach einem späteren Neustart, wird Knoten 1 erneut an der Replikation teilnehmen und nach einiger Zeit eventuell wieder "aufholen". Zu diesem Zeitpunkt wird nun die gesamte Prozedure mit vertauschten Knotenid's erneut durchgeführt und damit die ursprüngliche Situation wiederhergestellt. Serviceübernahme im Notfall Aufgrund der Möglichkeit das bestätigte Transaktionen die jedoch noch nicht erfolgreich repliziert wurden, "verloren" gehen ist diese Art der Serviceübernahme als "Worst-Case" Szenario für ein Master- Slave Replikationssystem anzusehen. Sollte die Möglichkeit bestehen den ausgefallenen Server wieder in Betrieb zu nehmen und sei es nur für wenige Minuten, so ist die im vorigen Absatz erläuterte Prozedure dringend zu empfehlen. Slony-I besitzt keine automatische Erkennung für ausgefallene Systeme. Der Verlust bereits bestätigter Transaktionen ist eine kommerzielle Entscheidung die nicht vom Datenbanksystem selbst getroffen werden kann. Falls nun jemand die folgenden Befehle in eineme Skript automatisiert von einem Netzwerküberwachungssystem ausführen lässt - Nunja es sind Ihre Daten ... Schritt 1) Das "slonik" Kommando failover (id = 1, backup node = 2); bewirkt das Knoten 2 ab sofort den Besitz aller Sets übernimmt die bisher der Knoten 1 besaß. Sollten sich noch weitere Knoten im System befinden, werden alle direkten Empfänger von Sets des Knotens 1 über diese Änderung informiert. Slonik wird darüberhinaus alle direkten Empfänger abfragen um denjenigen Knoten herauszufinden der den höchsten Replikationsstatus für das jeweilige Set besitzt. Die Konfiguration wird danach dahingehend geandert das der Knoten 2 zuerst alle Änderung dieses Knotens übernimmt bevor auch tatsächlich der Schreibzugriff auf die Tabellen erneut freigegeben wird. Weiters werden alle Knoten die direkte Empfänger von Knoten 1 waren, ab sofort Knoten 2 als Datenquelle für die entsprechenden Sets verwenden. Das heisst, dass sobald das "failover" Kommando durchgeführt wurde kein Knoten des Replikationssystems mehr Daten von Knoten 1 empfängt. Schritt 2) Rekonfiguration und Neustart der Applikation (oder von "pgpool") um einen erneuten Verbindungaufbau zum Knoten 2 zu erzielen. Schritt 3) Nachdem die Übernahme erfolgt ist und Knoten 2 nun Schreiboperationen akzeptiert, können alle verbleibenden Spuren von Knoten 1 mit dem folgenden slonik-Kommando entfernt werden: drop node (id = 1, event node = 2); Wiederinbetriebnahme von Knoten 1 nach der Übernahme Nach der Übernahme müssen alle auf Knoten 1 gespeicherten Daten als ungültig in Bezug zum Rest der Knoten betrachtet werden. Aus diesem Grund besteht die einzige Möglichkeit Knoten 1 wieder in Betrieb zu nehmen und erneut die Masterrolle zuzuweisen, darin ihn neu zu initialisieren. Nachdem er erneut syncronisiert ist kann eine kontrollierte Dienstübernahme mittels der Anfangs angefuhrten Prozedur durchgeführt werden.