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.
