MariaDB Cluster Vorfall

Letzten Samstag hatten wir unseren bisher größten Betriebsvorfall mit Flownative Beach : Ein MariaDB Galera Cluster fiel aus und konnte nur in einem degradierten Zustand wieder hochgefahren werden.

Dies führte zu einem Datenverlust der letzten drei Tage für 5 Websites (soweit wir wissen) und zu einer Ausfallzeit von etwa 60 Minuten für 62 Beach Instanzen. Zu den betroffenen Websites gehörten neos.io und flownative.com.

tldr; Wir werden auf ein neues Datenbank-Setup umstellen und werden dies heute im Laufe der Nacht tun. Wenn dein Projekt zwischen dem 22.10.2019 22:00 Uhr und dem 23.10.2019 02:00 Uhr Datenbankinhalte ändern wird, melde dich bitte bei uns, damit wir eine Lösung finden können.

Einige Hintergrundinformationen zu unserer Einrichtung

Seit etwa einem Jahr setzen wir MariaDB in unseren Kubernetes-Clustern ein. Um MariaDB widerstandsfähiger gegen Ausfälle der physischen Maschinen zu machen, auf denen es läuft, haben wir ein Setup mit MariaDB Galera Cluster entwickelt. Das bedeutet: Anstatt einen einzelnen Server zu verwenden, werden alle Daten auf einen zweiten Server repliziert. Ein Lastausgleichsmechanismus verteilt die Arbeitslast (deine SQL-Anfragen) auf diese beiden Server (konkreter: Wir betreiben Galera-Cluster mit zwei Knoten, Master-Master-Replikation und einem zusätzlichen Arbitrator-Knoten, der mit Hilfe von Anti-Affinitätsregeln auf verschiedene Kubernetes-Knoten verteilt wird).

Der Betrieb eines Galera-Clusters ist nicht trivial, und in einer Kubernetes-Umgebung ist er sogar noch schwieriger. Deshalb haben wir etwa zwei Monate Arbeit investiert, um eigene MariaDB-Galera-Docker-Images und Überwachungsskripte zu entwickeln.

Was geschah

Die Ursache dafür ist relativ einfach zu beschreiben. Und sie ist ziemlich peinlich: "kein Festplattenplatz mehr".

Jeder MariaDB-Knoten hat sein eigenes sogenanntes "persisted volume". Dabei handelt es sich um eine virtuelle SSD, die an den Container des Datenbankservers angeschlossen ist. Wenn dieses Volume voll ist, kann MariaDB keine weiteren Schreibvorgänge mehr verarbeiten und stürzt schließlich ab.

Im Allgemeinen haben wir einige Dinge getan, um diese Art von Abstürzen zu verhindern. Erstens haben wir (wenn auch manuell) den freien Speicherplatz überwacht und die Größe der Volumes bei Bedarf angepasst. Zweitens haben wir den Master-Knoten eine unterschiedliche Menge an Speicherplatz zugewiesen, damit sie nicht gleichzeitig voll laufen. Und schließlich haben wir daran gearbeitet, diese Aufgaben zu automatisieren und die Volumes automatisch wachsen zu lassen.

In diesem speziellen Fall schlugen diese Maßnahmen jedoch fehl: Die Festplattennutzung wuchs viel, viel schneller als erwartet und aufgrund eines Kopier- und Einfügefehlers hatte der Cluster am Ende auf beiden Master-Knoten die gleiche Volume-Größe.

Als einer der Knoten ausfiel, versuchte der andere Knoten, einzuspringen. Der erste Knoten wurde automatisch neu gestartet und versuchte, sich zu erholen - und weil der erste Knoten dann auch keinen Platz mehr hatte, stürzte auch er ab. So etwas nennt man einen vollständigen Clusterabsturz. In dieser Zeit versuchte der zweite (gesündere) Knoten, sich von den Daten des ersten Knotens zu erholen, die aufgrund des Absturzes unvollständig waren. Und so haben wir am Ende Daten von etwa drei Tagen verloren. Glücklicherweise haben die meisten Projekte, die diesen Datenbankserver nutzen, in dieser Zeit keine Inhalte bearbeitet.

Wie wir das Problem lösen werden

Wir haben mit einer Reihe von Leuten gesprochen, die Unternehmensprojekte betreiben, und sie standen auf die eine oder andere Weise vor ähnlichen Herausforderungen. Das Fazit für uns ist, dass Kubernetes (noch) nicht für den Betrieb von Datenbankservern geeignet ist (obwohl Oracle zum Beispiel eine Lösung für MySQL herausgebracht hat, die auf dem Operator Pattern basiert). Es ist sicherlich machbar, aber wenn man bedenkt, dass wir über eine Hosting-Umgebung ab 19€ pro Monat sprechen, ist es mit den Ressourcen, die wir haben, einfach nicht machbar. Und selbst die großen Cloud-Anbieter wie Google, AWS und Digital Ocean bieten immer noch keine MySQL-Cluster mit Master-Master-Replikation als Service an.

Was wir also gerade tun, ist die Rückkehr zu einem traditionelleren System: Wir migrieren alle Datenbanken zu Google Cloud SQL-Instanzen, die außerhalb von Kubernetes laufen. Sie verfügen über automatisch wachsende Volumes - allerdings skalieren CPU und Speicher nicht automatisch. Außerdem müssen diese Server neu gestartet werden (und verursachen dann ein wenig Ausfallzeit), wenn Wartungsaufgaben anstehen. Aber ein paar Sekunden Ausfallzeit im Monat stehen in keinem Verhältnis zu den möglichen Datenverlusten bei einem fortschrittlicheren System.

Die Migration

Während der Migration erstellen wir einen neuen Speicherauszug deiner Datenbanken und importieren ihn in den neuen Cloud SQL Server. Sobald das erledigt ist, werden wir deine Instanzen mit den aktualisierten Datenbankanmeldeinformationen neu einrichten.

Wir werden heute in der Nacht auf die neue Datenbankeinrichtung umstellen. Alle inhaltlichen Änderungen, die zwischen dem Export und dem Wechsel auf den neuen Server vorgenommen wurden, gehen verloren. Wenn du also weißt, dass dein Projekt zwischen dem 22.10.2019 22:00 Uhr und dem 23.10.2019 01:00 Uhr Datenbankinhalte ändern wird, melde dich bitte bei uns, damit wir eine Lösung finden können.

Wir wissen, dass diese Ankündigung sehr kurzfristig kommt, aber wir müssen die Inhalte unbedingt aus dem alten Cluster herausbekommen, damit wir nicht daneben sitzen und Händchen halten müssen, du weißt schon ...

Fazit

Das war kein Spaß, weder für uns, noch für die Kunden, die von diesem Ausfall betroffen waren. Das tut uns sehr leid (auch weil wir selbst wieder einige Inhalte schreiben mussten).

Ich hoffe, wir konnten dir einen Einblick geben, was passiert ist und wie wir mit dem Problem umgehen. Wenn du Fragen hast oder Hilfe brauchst, um deinen Kunden die Angelegenheit zu erklären, lass es uns bitte wissen.

Und dann, viel Spaß auf Beach - das Wetter wird Ende dieser Woche wieder schön sein!

Dein Flownative Team