Das Update auf MariaDB 10.3
Das Update auf MariaDB 10.3
Eine Geschichte aus dem Lehrbuch: Wie man es nicht machen sollte.
Auf olbers, encke, neujmin, kopff, brooks lief MariaDB die letzten Tage leider alles andere als stabil. Dafür möchten wir uns entschuldigen und im gleichen Atemzug erklären was passiert ist und welche Lehren wir aus dem Vorfall ziehen - so transparent wie ihr es von uns gewohnt seid.
Was ist passiert?
Es gibt bei uns seit nunmehr 9 Monaten ein Issue zum Update auf MariaDB 10.3 und im Support laufen immer mehr Rückfragen auf, wann wir denn endlich das Update einspielen. Immer mehr Software läuft nicht oder nur mit Sprüngen durch brennende Reifen mit MariaDB 10.0, wie z.B. BookStack oder Gitea. Wir haben am 16.10. begonnen, das Update einzuspielen und uns dabei ordentlich in die Nesseln gesetzt.
Ablauf
Das Update Playbook haben wir am 12.10. nach bestem Wissen und Gewissen geschrieben. Die MariaDB-Dokumentation beschreibt die notwendigen Schritte ausführlich, ich selbst habe noch zwinkernd folgenden Kommentar am Issue hinterlassen:
Was kann da schon schief gehen? Hier das Playbook, welches am 15.10. durch unseren internen Reviewprozess (jede Zeile Code muss von einem zweiten Paar Augen abgenommen werden) durchgewunken wurde:
---
- name: get the rpm package versions
package_facts:
- name: get installed mariadb version
set_fact:
installed_version: "{{ ansible_facts.packages['MariaDB-server'][0].version.split('.')[:2] | join('.') }}"
- block:
- name: stop mariadb for upgrade
service: name=mysql state=stopped
- name: uninstall mariadb for upgrade
yum: name={{ item }} state=absent
with_items:
- MariaDB-server
- MariaDB-client
- name: install new mariadb version
yum: name={{ item }} state=latest
with_items:
- MariaDB-server
- MariaDB-client
when: mysql_version != installed_version
# these two are a no-op on already upgraded databases, but we want to make sure
# they also run in case of a crash in the code above.
- name: start mariadb again
service: name=mysql state=started
- name: migrate databases to new mariadb version
command: mysql_upgrade
Das Update haben wir am 16.10. eingespielt und das sah soweit erst mal gut aus: Auf einem Testhost (im Screenshot Canary) mit 200 Usern lief alles einwandfrei - das Update lief durch, die Migration lief durch, keinerlei Auffälligkeiten oder gar Ausfälle.
Wir waren uns also sicher, dass alles glatt gehen würde und haben den weiteren Rollout angestoßen, aktuell werden immer 10 Hosts gleichzeitig von der CI geupdated, als erstes borrelly, holmes, brooks, kopff, gale, crommelin, neujmin, westphal, whipple und wirtanen:
TASK [mysql : start mariadb again] *********************************************
Monday 15 October 2018 16:50:56 +0000 (0:02:43.558) 1:24:48.831 ********
changed: [borrelly.uberspace.de]
changed: [holmes.uberspace.de]
fatal: [brooks.uberspace.de]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mariadb.service failed because a fatal signal was delivered to the control process. See \"systemctl status mariadb.service\" and \"journalctl -xe\" for details.\n"}
fatal: [kopff.uberspace.de]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mariadb.service failed because a fatal signal was delivered to the control process. See \"systemctl status mariadb.service\" and \"journalctl -xe\" for details.\n"}
changed: [gale.uberspace.de]
changed: [crommelin.uberspace.de]
fatal: [neujmin.uberspace.de]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mariadb.service failed because a fatal signal was delivered to the control process. See \"systemctl status mariadb.service\" and \"journalctl -xe\" for details.\n"}
changed: [westphal.uberspace.de]
changed: [whipple.uberspace.de]
changed: [wirtanen.uberspace.de]
Hier sieht man etwas, was in der Produktion niemals vorkommen sollte, bei 5 von 10 Hosts hat’s den MariaDB-Service gerissen. Auf den betroffenen Hosts war der Service so kaputt, dass wir letztendlich alle Datenbanken dumpen, eine komplett neue MariaDB-Installation aufsetzen mussten und die Daten wieder einspielen mussten. Teilweise lief auch das nicht, bei manchen Views mussten wir händisch in den Dump eingreifen und reparieren. Das ist auch der Grund, warum der ganze Vorfall zwei Tage angedauert und uns schlaflose Nächte bereitet hat.
Ursachen
Wir können zum jetzigen Zeitpunkt noch nicht genau sagen, was genau eigentlich das Problem war und sind noch in der Analyse. Vermutlich war der Sprung von Version 10.0 auf 10.3 zu hoch. Es gibt außerdem einen Bugreport, der zum Fehlerbild passt. Wir halten euch hier auf dem Laufenden.
Learnings
- Es ist eigentlich trivial und uns deshalb um so unangenehmer: Wir haben direkt vor dem Update kein Backup von
/var/lib/mysqlerstellt. Die täglich automatisch erstellten Backups waren zu dem Zeitpunkt zu alt. Das passiert uns auf keinen Fall noch mal… - Wir haben zwar die allgemeine Dokumentation für Updates berücksichtigt, aber nicht die für die einzelnen Versionssprünge. Evtl. hätte die Option
innodb_fast_shutdown=0das Problem verhindert. Auch für uns gilt: RTFM! - Wir werden in Zukunft keine Versionen beim Update überspringen. Statt
10.0->10.3hätte10.0->10.1->10.2->10.3mit jeweiliger Migration das Problem vielleicht verhindern können. - Allen Beteiligten war nicht ganz klar, dass dieses Update ein wirklich dickes Schiff ist und auch breaking changes mitbringt. Es ist das erste Mal, dass wir MariaDB ein Major Upgrade verpassen. Auch das wird uns so nicht wieder passieren.
- Wir werden Major Upgrades in Zukunft vorher ankündigen und uns darum kümmern, dass wir mit der Konfiguration kompatibel zur vorherigen Version bleiben.
Fazit
Jeder kennt das Sprichwort: Wo gehobelt wird fallen Späne und bei Uberspace 7 wird ordentlich gehobelt damit wir euch neue Features bringen können. Wir wollen nicht, dass der Eindruck entsteht, dass wir euch ein instabiles oder unausgereiftes Produkt liefern. Ab und zu geht etwas schief, das war damals™️ bei Uberspace 6 nicht anders, da wir da aber nur noch Maintenance vornehmen und keine neuen Features implementieren, gerät das schnell in Vergessenheit.
Ein Kollege sagt gerne: “Haben wir was richtig gemacht oder haben wir etwas gelernt?” Heute haben wir auf jeden Fall etwas gelernt.