Icon Rufen Sie uns an
+49 441.309197-69 +49 441.309197-69
 
DE

Manchmal geht ein Update schief

Posted by Felix Kronlage on Wednesday, August 03, 2011

Eigentlich wollten wir hier heute einen Blog-Artikel über das Update unserer Hosted-Zarafa Plattform auf Zarafa 7 veröffentlichen. Gelegentlich kommt es aber anders, in diesem Fall schlug das Update fehl und wir laufen noch mit Zarafa 6.40.×. Das ein problemloser Rollback möglich war, liegt an verschiedenen Faktoren und soll auch der Fokus dieses Blogposts sein. Dies soll kein Upgradeguide für Zarafa 7 sein, da gibt es wesentlich bessere Quellen, wie zum Beispiel das entsprechende Kapitel im Zarafa Admin Manual.

Wie bereite ich mich darauf vor, dass ein solches Update fehlschlägt?

Wir haben intern schon eine ganze Zeitlang einen Zarafa 7 Server, und haben diesen auch bereits in der Beta-Phase von 6.40 auf 7 angehoben. Das ging problemlos, wobei die Datenmenge natürlich eine andere ist, als bei uns auf dem Hosted Zarafa.

Als Hintergrund: Mit Zarafa 7 kommt auch die Umstellung auf UTF-8 sowie diverse weitere Änderungen an der Datenbankstruktur. Hierzu ist es notwendig, dass das entsprechende Update-Skript (zarafa7-upgrade) verwendet wird, oder der Zarafa-Server mit der entsprechenden Option, --force-database-upgrade gestartet wird.

Je nach Datenbankgrösse, dem darunter liegenden Storage und weiteren Faktoren geht dies schneller — oder eben auch nicht. Dies war auch das, was uns beim Update in die Falle hat laufen lassen: die Konvertierung der Datenbank dauerte und dauerte. Damit wir einen sauberen Betrieb zum heutigen Arbeitstagbeginn garantieren konnten, musste das Update inkl. anschliessender Tests bis 6 Uhr fertig sein. Um 5:30 Uhr waren laut Fortschrittsanzeige von zarafa7-update (der Grund, warum man lieber das Skript, statt zarafa-server --force-database-upgrade verwenden will) 68% der Datenbank konvertiert. Es war also klar, wir müssen zurück auf 6.40.

Die Versicherung: Rücksprungposition erstellen

Wenn man die Möglichkeit hat, kann man eine passende Rücksprungposition z.B. durch das Snapshotting einer VM erreichen. Wichtig: Ist die Rücksprungposition erstellt, darf es keine Änderungen mehr geben, die nicht zum Update gehören.
Bei einem Mailsystem, wie bei einem Zarafaserver, bedeutet dies:

- Sicherstellen, dass es keinen eingehenden Mailverkehr gibt (Blockieren von SMTP im Paketfilter oder Beenden des MTA)
- Sicherstellen, dass die Benutzer keine Änderungen vornehmen können. Im Falle eines Zarafa-Servers wird dies durch das Beenden aller Zarafa-Prozesse gewährleistet. Damit die Benutzer aber nicht unnötigerweise Fehlermeldungen bekommen, sollte man auch den Webserver beenden (WebAcces, z-push).

In unserem Falle kam Snapshotting nicht in Frage, weswegen unsere Rücksprungposition durch Sicherung des Datenbestandes erfolgte:

1) mysqldump (--single-transaction benutzen, nur die Zarafa-DB dumpen). An dieser Stelle kann man natürlich auch bei angehaltenem MySQL Server /var/lib/mysql kopieren.
2) /etc/zarafa
3) /var/lib/zarafa

Im besten Falle vertraut man darauf, dass der Dump funktioniert. Ist man skeptisch, kann man diesen auf einem anderen System importieren. Achtung, auch dies kann – je nach Grösse – eine beträchtliche Zeit in Anspruch nehmen. Hier gilt: Zeit nehmen. Solche Schritte in Hektik auszuführen, schreit nach Problemen.

Eine Rücksprungposition heisst auch, dass man die Zarafa-Pakete der Originalinstallation noch zur Hand haben sollte.

Der Abbruch

Entscheidet man sich an einem bestimmten Punkt dazu, ein solches Update abzubrechen, geschieht dies in der Regel aus der Not heraus, zum Beispiel, weil einem die Zeit wegläuft. Das Fatale an der Situation: Man ist sowieso schon unter Druck. An dieser Stelle gilt, was wir unseren Leuten bei bytemine als Erstes beibringen:

DON’T PANIC.

Je kühler der Kopf, desto besser. Es gibt Menschen die können das von Natur aus, andere neigen dazu in solchen Situationen nervös zu werden. Ich persönlich zähle leider nicht zu der ersten Gruppe und hab mir deshalb über die Jahre Muster angewöhnt, die ich verwende um ruhig zu bleiben. Neben Erfahrung ist die Kunst in solchen Situationen ruhig zu bleiben mit das Wichtigste. Wiederum gilt: An dieser Stelle hektisch zu werden nützt niemandem.

Etwas was sicherlich hilft, ist ein zweiter Leitspruch den wir bei bytemine haben (und aus dem OpenBSD Umfeld abgekupfert haben): Only failure makes us experts. Durch die gute Vorarbeit bei der Rücksprungposition können wir uns erlauben, das Update abzubrechen. Dieses Gefühl ist wichtig. Hat man bei der Vorarbeit gepfuscht, ist es an diesem Punkt wesentlich schwieriger die Entscheidung “Ja, Update abbrechen” zu fällen.

Zurück zum Zarafa Beispiel. Ich hab also das zarafa7-upgrade Script abgebrochen und mir erstmal in Ruhe den Pfad zur Rücksprungposition überlegt:

  1. Zarafa 7 Pakete deinstallieren
  2. Datenbank-Dump in alternative DB importieren (zarafa6 z.B.)
  3. Zarafa 6 Pakete installieren
  4. Alles wieder starten

Die Zarafa 7 Pakete zu deinstallieren ist nicht schwer, nur das zarafa-server Paket liess sich zunächst nicht deinstallieren. Jedesmal wenn ich es deinstallieren wollte, wurde ein pre-rm Skript ausgeführt, welches /etc/init.d/zarafa-server aufrief. Dadurch gab es Fehler und die Deinstallation wurde abgebrochen. Kurzerhand: exit 0; an den Anfang des init.d Scripts.

Während der Import des Datenbank-Dumps lief, installierte ich dann schonmal die Zarafa 6 Pakete, habe vorher jedoch sichergestellt, dass /etc/zarafa nicht existiert, da ich vermeiden wollte, das beim Installieren der Pakete ggf. der Server gestartet wird und auch auf die DB zugreift.

Die Kopie von /var/lib/zarafa brauchte ich letztendlich nicht, dies war nur für den Fall dass dort auch beim Upgrade Änderungen geschehen.

Jetzt müssen wir nur noch unsere Hausaufgaben machen und schauen, warum die Konvertierung so lange gedauert hat….