Am 17.9.2014 kam es bedauerlicherweise zu einem schweren Crash des MySQL-Servers für kostenlose Benutzer. Premium-Benutzer waren nicht betroffen. In diesem Blogpost wird werden wir die Ursache und den Umfangs des Schadens beleuchten. Betroffene Benutzer, die Daten verloren haben oder deren Tabellen beschädigt wurden melden sich bitte per Support-Ticket (in der Verwaltung) unter Angabe des Datenbank-Namens. Wir erstellen gerade eine Liste aller noch betroffenen Tabellen und melden uns bei den betroffenen Benutzern per Ticket.
Zeitlicher Verlauf
Am 17.9. gegen 16:25 wurde der Datenbank-Server für angekündigte Wartungsarbeiten heruntergefahren. Die defekte Hardware wurde getauscht, getestet und um 16:48 wurde der Datenbank-Server wieder gestartet. Der MySQL-Server wurde gestartet, hat aber den Timeout des Prozess-Managers für den Start überschritten und wurde als „nicht gestartet“ markiert, woraufhin ein erneuter Versuch unternommen wurde. Der zweite MySQL-Prozess versuchte, auf die Daten-Dateien der InnoDB-Storage-Engine zuzugreifen, die von dem anderen Prozess erwartungsgemäß gesperrt waren. Dabei scheint eine Race Condition aufgetreten zu sein, die im zweiten Prozess den Crash-Recovery-Vorgang von InnoDB gestartet hat. Der Versuch, die Crash-Recovery-Daten auf den gesperrten Tablespace anzuwenden hat den Tablespace irreparabel beschädigt. Nachdem beide Prozesse von einem Administrator gestoppt waren war der Schaden bereits angerichtet.
Der MySQL-Prozess ließ sich anschließend nicht mehr starten, da der defekte Tablespace einen Bug in MySQL ausgelöst hat (so sieht das aus). Der Versuch, den Tablespace um die defekten Datenbanken zu bereinigen und sofort zum Laufen zu bekommen schlug fehl, so dass wir eine Liste aller Datenbanken erstellen mussten, die InnoDB-Tabellen enthielten. Dieser Vorgang dauerte bis ca. 20:00. Diese Datenbanken haben wir anschließend mittels mysqldump exportiert, während InnoDB im „forced recovery“-Modus lief. Gegen 1:00 war dieser Vorgang abgeschlossen, 41 Datenbanken ließen sich nicht mehr exportieren. Anschließend haben wir einen neuen InnoDB-Tablespace erstellt, den MySQL-Server mit dem neuen Tablespace (und damit ohne die InnoDB-Tabellen) gestartet und den Import der exportierten Datenbanken gestartet. Der Import wurde am Morgen des 18.9. abgeschlossen.
Schadensumfang
Bei der Prüfung, wie viele und welche InnoDB-Tabellen existierten stellte sich heraus, dass eine mittlere vierstelle Anzahl von Datenbanken InnoDB-Tabellen enthielten. Davon konnten wir gut 90% der Datenbanken ohne Probleme wiederherstellen. Bei den verbleibenden Datenbanken fehlen Daten der letzten Tage, da diese beim Anwenden des Recovery-Logs durch MySQL verloren gingen. In etwa 0,2% der Fälle sind Tabellen vollständig verloren gegangen.
Für so gut wie alle beschädigten Datenbanken existierte ein Backup.
Konsequenzen
Eine wichtige Sache haben wir gelernt: niemals, NIEMALS darf ein MySQL-Prozess doppelt laufen. Damit das nicht noch einmal passiert startet der Datenbank-Server die MySQL-Prozesse nicht mehr automatisch, sondern ein Administrator muss den Prozess starten. Die Ursache für das Problem ist damit unterbunden.
Wir öffnen bei jedem Benutzer, der noch betroffen ist, ein Ticket um zu erfahren, ob der rückgesicherte Stand in Ordnung ist oder noch etwas zu tun ist.
Wir entschuldigen und für die Unannehmlichkeiten und bedanken uns für die vielen aufmunternden Worte 🙂
