Vor kurzem haben wir vom RZ einen weiteren Server erhalten, der uns als dedizierter Datenbankserver dabei helfen soll, mit den hohen Zugriffszahlen kurz vor den Klausuren am Ende des Semesters zurecht zu kommen. Damit haben wir zwei vom RZ gehostete Server, die aber leider zuerst keine aufeinanderfolgende IP-Adressen hatten.
Schon das Umbauen der Datenbank von unserem bisherigen Server auf einen anderen Server hat uns letztlich 90 Minuten Ausfallzeit gekostet (solange hat es gedauert, die 20GB MySQL/InnoDB-Daten auf den anderen Server zu kopieren). Dann dauerte es wieder ein paar Stunden, bis auch der MySQL-Slave (von dem wir das Backup machen) wieder auf dem aktuellen Stand war.
Da uns das RZ gebeten hat, aus verwaltungstechnischen Gründen den CaseTrain-Server auf eine IP neben der IP des Datenbankservers zu ziehen, kam gestern bzw. heute dann der IP-Umzug und dabei sind die Probleme aufgetreten, die dazu geführt haben dass vom 19.11.2012 16:27 bis 20.11. 11:52 keine Fallbearbeitungen protokolliert wurden. Und das kam so:
In MySQL kann und sollte man Benutzeraccounts auf IP-Adressen beschränken. Für die verschiedenen Anwendungen gibt es im CaseTrain-System verschiedene Accounts, unter anderem einen für den Zugriff auf die Datenbank, in der die Bearbeitungen gespeichert werden. Vor dem Umzug auf die neue IP wurden alle Accounts kopiert und auf die neue IP geändert, so dass es jeden Account zweimal gab (jeweils für die alte IP und für die neue IP). Dieser eine Account wurde dabei vergessen. Als dann gestern für eine Übergangszeit von einem Tag der Server so umgestellt wurde, dass er unter beiden IP-Adressen erreichbar ist (was notwendig ist, da nicht alle DNS-Server, die die Adresse casetrain.uni-wuerzburg.de zur IP auflösen gleichzeitig und sofort wissen, dass CaseTrain einen neue IP hat und deswegen noch bis zu 24h lang die alte IP liefern), wurde dies so konfiguriert, dass die neue IP die primäre IP ist.
Als CaseTrain dann mit der IP auf die Bearbeitungen-Datenbank zugreifen wollte, ging das nicht und es gab einen Fehler, der auch protokolliert wurde. Davon merkte zunächst niemand etwas - den Fallbearbeitern wird nicht angezeigt, dass die Bearbeitung nicht protokolliert wird und auch sonst ist es keinem aufgefallen. Es kamen abends zwei Tickets an, dass Fallbearbeitungen nicht abgespeichert wurden, aber das war schon außerhalb der Bürozeiten und deswegen wären die Tickets auch heute erst im Laufe des Tages bearbeitet worden.
Heute morgen wurde dann der DNS-Eintrag umgestellt, so dass casetrain.uni-wuerzburg.de nun auf die neue IP verweist und mehr oder weniger sofort ging gar nichts mehr - https://casetrain.uni-wuerzburg.de reagierte nicht http://casetrain.uni-wuerzburg.de/manager (worüber die Fälle gestartet werden) führte zu einem 404-Fehler. Nach einem Neustart des Apache httpd Webserver waren plötzlich die Konfigurations-Dateien leer und nur noch 0 Byte groß? Apache tomcat ließ sich gar nicht mehr neu starten? Was ist da los? Es hat ein bisschen gedauert, bis bemerkt wurde, dass das Fehlerprotokoll, das seit dem 19.11. fleißig die Probleme bei der Datenbankverbindung protokolliert hat, inzwischen den gesamten Plattenplatz für sich beansprucht, so dass kein Byte mehr geschrieben werden konnte - und deswegen konnte der tomcat nicht mehr starten und deswegen hat der httpd beim Starten die Konfigurationsdatei geleert.
Nachdem der fehlende Account eingetragen war und die Dienste alle erfolgreich gestartet werden konnten, funktionierte dann zwar alles wieder - aber leider fehlen uns bzw. den fleißigen Fallbearbeitern VÖLLIG UNNÖTIG über 17h Fallbearbeitungsprotokolle und wir hatten über 2h Ausfallzeit.
Mist.
Keine Kommentare:
Kommentar veröffentlichen