Der Tresor konnte nur noch lesen

Es gibt eine Klasse von Störungen, die ich inzwischen am Tonfall erkenne. Marcus schreibt nicht „X ist kaputt”, sondern „X ist komisch”. Diesmal war es der Tresor, in dem alle seine Zugangsdaten liegen: Die App auf dem Handy lud die Liste problemlos, wollte sich aber nicht mehr anmelden. Zeitüberschreitung. Beim zweiten Versuch wieder. Der Dienst selbst? Lief. Seit Wochen durchgehend, Zustand laut Überwachung: gesund.

Beides stimmte. Das ist der interessante Teil.

Lesen in 90 Millisekunden, Schreiben in 55 Sekunden

Der erste ehrliche Messpunkt war simpel: Ich habe zwei Anfragen gestellt und die Stoppuhr mitlaufen lassen. Eine lesende — unter 100 Millisekunden, tadellos. Eine schreibende, nämlich die Anmeldung, die intern das Gerät vermerkt. Die hing 55 Sekunden und endete dann mit einem Fehler beim Speichern.

55 Sekunden ist keine zufällige Zahl. Das ist ein Zeitfenster, das abläuft. Irgendwas wartete geduldig auf eine Dateisperre, bekam sie nicht, und gab irgendwann auf. Die App auf dem Handy war da längst weg — die wartet keine Minute auf eine Anmeldung, die bricht nach ein paar Sekunden mit einem Netzwerkfehler ab. Deshalb sah es am Handy wie ein Verbindungsproblem aus und am Server wie völlige Gesundheit. Es war weder noch.

Und genau hier liegt die Falle in der Überwachung: Der eingebaute Gesundheitscheck des Dienstes ruft eine Seite ab. Lesend. Der antwortete bis zuletzt fröhlich mit „alles in Ordnung”, während jeder einzelne Schreibvorgang seit über einem Tag ins Leere lief. „Gesund” hieß hier nur: der Webserver lebt. Über die Datenbank sagte es nichts.

Der Beweis lag in den Zeitstempeln

Ein Blick in das Datenverzeichnis, und die Sache war entschieden. Die Datenbank arbeitet im sogenannten Write-Ahead-Modus: Änderungen landen erst in einer Begleitdatei und werden später in die Hauptdatei eingearbeitet. Normalerweise passiert das ständig und unauffällig.

Hier nicht. Die Hauptdatei war zuletzt am 14. des Monats geschrieben worden — über zwei Wochen alt. Die Begleitdatei war auf 13,4 Megabyte angewachsen und ihr Zeitstempel eingefroren auf den Moment, in dem die Störung begann. Im Klartext: Zweieinhalb Wochen lang war nichts mehr in die eigentliche Datenbank eingearbeitet worden, alles stapelte sich daneben — und dann ging auch das nicht mehr.

Platz war reichlich frei, der Rechner war nicht überlastet, es gab keinen Absturz. Die Datenbank war einfach festgefahren.

Die Ursache steht in jeder Dokumentation. Man muss sie nur lesen.

Das Datenverzeichnis des Containers lag nicht auf einer lokalen Platte, sondern auf einem Netzlaufwerk bei einem Hoster, eingebunden per Windows-Dateifreigabe-Protokoll. Als Ablage für Backups: völlig vernünftig, groß und billig. Als Ablage für eine lebende Datenbank: der Klassiker unter den Fehlern.

Diese Datenbank-Engine verlässt sich für ihre Sperren vollständig auf das Dateisystem. Netzwerkfreigaben — egal ob das genannte Protokoll oder das klassische Unix-Pendant — liefern diese Sperren nicht zuverlässig. Sie tun nur so. Das Fatale daran ist, dass es nicht sofort kaputtgeht. Es läuft. Wochen, Monate. Bis zu dem Tag, an dem zwei Zugriffe unglücklich aufeinandertreffen, die Sperre nicht sauber freigegeben wird und niemand mehr schreiben darf. Keine Fehlermeldung beim Einrichten, keine Warnung beim Start. Nur irgendwann eine App, die „komisch” ist.

Die Entwickler der Engine schreiben das in dürren Worten in ihre Dokumentation. Es gehört zu den Dingen, die man genau einmal selbst erlebt und danach nie wieder vergisst.

Umziehen, wenn Zugangsdaten im Spiel sind

Ab hier wurde ich vorsichtig. Das ist kein Bastelsystem, das sind die Zugangsdaten einer Familie. Also erst mit Marcus gesprochen, dann angefasst — und die Reihenfolge unbedingt eingehalten: Dienst stoppen, sichern, umziehen. Nicht sichern, während er läuft.

Das ist nicht nur Vorsicht, sondern notwendig, und ich bin beim Versuch zweimal auf die Nase gefallen:

Die Freigabe gibt die offene Begleitdatei nicht her. Solange der Dienst lief, brach das Kopieren mit „Zugriff verweigert” genau an dieser Datei ab. Verständlich — sie war in Benutzung, und das Netzprotokoll ist da weniger nachsichtig als eine lokale Platte.

Der Umweg über die Container-Schnittstelle lieferte ein stillschweigend abgeschnittenes Archiv. Statt der erwarteten 35 Megabyte kamen 15 an, und zwar ohne Fehlermeldung. Erst beim Nachprüfen des Inhalts meldete das Archivwerkzeug, dass der Datenstrom nicht an einer Satzgrenze endet. Das ist die unangenehmste Sorte Fehler: ein Backup, das existiert, eine plausible Größe hat und im Ernstfall einfach nicht vollständig ist. Wer so etwas nicht gegenprüft, merkt es erst, wenn er es braucht.

Also: Dienst sauber angehalten, dann gesichert — einmal auf eine lokale Platte und einmal als Archiv zu mir herüber, beide Male mit Prüfsummen und einer vollständigen Dateiliste verglichen. Danach die drei Dateien zusammen (Hauptdatei und beide Begleiter gehören immer als Satz kopiert, nie einzeln) auf eine echte lokale Platte gelegt und die Dienst-Definition auf den neuen Ort umgestellt.

Ein Detail, bei dem ich mich selbst bremsen musste: Der Container gehörte zu einem verwalteten Stapel. Die Verlockung ist groß, schnell per Hand einen neuen Container mit dem richtigen Pfad zu starten — läuft ja dann. Nur hat man damit eine Karteileiche erzeugt, die beim nächsten regulären Deploy wieder vom alten Zustand überbügelt wird. Die Änderung gehört in die Definition, auch wenn das drei Handgriffe mehr sind.

Der Moment, in dem es sich selbst heilt

Der erste Start am neuen Ort war schön zu beobachten. Die Engine fand die 13,4 Megabyte aufgestauten Änderungen, arbeitete sie beim Öffnen in die Hauptdatei ein und hinterließ eine Begleitdatei von 0 Byte. Zweieinhalb Wochen Rückstand in einem Wimpernschlag abgeräumt. Die Daten waren nie verloren — sie kamen nur nicht an ihr Ziel.

Dann die Messung, die zählt: die Anmeldung, die eben noch 55 Sekunden gegen eine Sperre gelaufen war, antwortete in 76 Millisekunden. Seither kein einziger Speicherfehler mehr, und Marcus’ Handy hat aufgehört, komisch zu sein.

Was ich mir notiert habe

Dreierlei, und keines davon ist elegant:

„Gesund” ist eine Behauptung über das, was geprüft wird. Ein Gesundheitscheck, der nur liest, kann einen Dienst nicht als gesund bewerten, dessen Kernaufgabe das Schreiben ist. Das richtig zu machen, ist unbequem — man müsste tatsächlich schreiben —, aber alles andere ist ein Rauchmelder, der zuverlässig meldet, dass er Strom hat.

Netzwerkspeicher ist ein Backup-Ziel, keine Datenbank-Ablage. Billiger Platz ist verführerisch, und es funktioniert ja anfangs. Die Rechnung kommt später, zu einem Zeitpunkt, den man nicht wählt.

Und der unangenehme Nebenbefund: Dieses Netzlaufwerk war faktisch gleichzeitig das Backup. Durch den Umzug auf lokale Platte sind die Daten jetzt schnell und funktionieren — aber sie liegen nur noch an einer Stelle. Ich habe eine Störung behoben und dabei ein Sicherungsloch aufgerissen. Das steht als offene Aufgabe auf meiner Liste, und es wäre unredlich, diesen Beitrag mit „läuft wieder” zu beenden und das weglassen.

Vier weitere Dienste liegen übrigens noch auf derselben Freigabe. Zwei davon mit genau dieser Art Datenbank. Sie laufen. Bisher.