Source: Pixabay
As some of you may have noticed, RWTHmoodle was unavailable to RWTH Aachen University employees and students for a total of two days in the second week of June 2021. As we already reported on our channels during the malfunction, a serious database error was the cause. We would like to take this opportunity to briefly explain how this error occurred.
What happened?
In the morning of the first day (14.06.2021) of the malfunction, a major change of data took place on the database cluster of RWTHmoodle. Usually, this is a normal process. In the case, however, this was rejected by the system due to its size. This is also a normal process, which is primarily intended to ensure the security and integrity of the databases. The rejection of the changes nevertheless led to far-reaching restrictions in the operation of the database cluster. Of five nodes that are normally available, two failed. This ultimately led to the cluster operating with only three for about 30 minutes. All attempts by colleagues from the specialist department, who were already working flat out at the time to solve the problem, to reintegrate the two failed nodes into the cluster were unsuccessful up to that point.
Finally, the manufacturer’s technical support was contacted and a Prio 1 ticket was opened in order not to lose any more time. In the meantime, access to RWTHmoodle was blocked for users in order to prevent data loss.
First analyses of the manufacturer support pointed to known bugs in the current MySQL version, which is used on the cluster. However, since the possible solutions offered by the manufacturer’s employees did not lead to success, it was decided during the second day of the malfunction (15.06.2021) to stop the entire database cluster, delete it completely and set it up again. This was successfully accomplished during the course of the day, so that the cluster and RWTHmoodle were completely functional and usable again on the morning of the third day (16.06.2021). At this point, it should be mentioned that a data loss could be avoided and that the imported backup had the status of the evening of the first day.
Findings and measures
Based on the initial findings obtained during the incident together with the manufacturer, adjustments were made to the operating mode of the database cluster in order to prevent the occurrence of the aforementioned bugs in the future. The bugs themselves are to be fixed by the manufacturer in one of the future MySQL versions. Of course, these would then be extensively tested by our specialist department and a return to the previous operating mode would be examined.
In addition, various concepts are currently being evaluated in order to be able to avoid this and similar problems in principle in the future.
However, since disruptions can never be ruled out, we ask you to contact the IT-ServiceDesk in urgent cases.
Responsible for the content of this article is Anastasios Krikas.
Ich finde es gut, dass hier der Versuch unternommen wird, Informationen zum Ausfall von Moodle zu liefern. Das ist schonmal ein Fortschritt seitens des ITCs.
Leider kommt dieser Bericht, aber nicht am Niveau einen Post-Mortem oder erklärt überhaupt die Frage #woranhatetjelegen (wie dieser Artikel auf Twitter beworben wurde).
Was war dieser “schwerwiegender Datenbankfehler” oder was waren die ursächlichen “größere Änderung der Daten” (INSERTs, UPDATEs, Migrationen, …), welche Versionen wurden eingesetzt?
“The cost of failure is education.” – Devin Carraway
Da ja nicht nur das ITC Moodle mit MySQL einsetzt, könnten die auftretenden Probleme ja auch bei anderen auftreten.
Beispielsweise bei Betreibern von Moodle Instanzen infra.run (für das Land Berlin) oder Belwue finden sich detalierte Fehlerberichte.
Mit einen detaillierten Fehlerbericht könnte das ITC ja ganz im Sinne des Opensorce Gedankens der genutzten Software Moodle anderen Betreibern aus der eigenen Erfahrungen heraus Anhaltspunkte zu möglichen Problemquellen etc. liefern.
Hallo Paul,
vielen Dank für dein konstruktives Feedback zu unserem Nachbericht.
Wir geben dieses gerne an die zuständigen Personen weiter.
Wir haben uns explizit für eine solche Beschreibung entschieden, um möglichst vielen Leser*innen verständlich darzustellen was passiert ist.
Gerne liefern wir an dieser Stelle noch eine detailliertere Beschreibung:
Wir verwenden den InnoDB Cluster zur Ausfallsicherheit und Lastverteilung.
Der Bug hängt mit dem Consistency Level zusammen. Das Consistency Level beschreibt, wie sichergestellt wird, dass Daten zwischen den Knoten konsistent bleiben.
Wir hatten ein Level eingestellt, der höchste Konsistenz bietet.
Im Zuge der Störung haben wir nach Erkenntnissen und Empfehlung des Supports des Herstellers das Level geändert, welches nicht vom Bug betroffen ist.
Somit konnten wir im Anschluss den Betrieb von RWTHmoodle und des Datenbankclusters aufnehmen.
Welche „größere Änderung der Daten“ das war, konnten wir leider nicht herausfinden. Wie im Blogbeitrag beschrieben ist das auch ein normales Verhalten.
Wir befinden uns momentan noch im Austausch mit dem Hersteller, um eine tiefergehende Analyse durchzuführen.
Grundsätzlich sind wir mit der Moodle-Community in regelmäßigem Austausch und dort wird sich auch über solche Probleme ausgetauscht.
Dafür nutzen wir etablierte Kanäle (z.B. das HU-Forum und Community-Treffen).
Wir hoffen, dass dir unsere Antwort weiterhilft.
Viele Grüße,
das IT Center Blog Team