/ Uberspace7

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:

Kommentare am Issue

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.

CI Screenshot

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

  1. Es ist eigentlich trivial und uns deshalb um so unangenehmer: Wir haben direkt vor dem Update kein Backup von /var/lib/mysql erstellt. Die täglich automatisch erstellten Backups waren zu dem Zeitpunkt zu alt. Das passiert uns auf keinen Fall noch mal...
  2. 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=0 das Problem verhindert. Auch für uns gilt: RTFM!
  3. Wir werden in Zukunft keine Versionen beim Update überspringen. Statt 10.0 -> 10.3 hätte 10.0 -> 10.1 -> 10.2 -> 10.3 mit jeweiliger Migration das Problem vielleicht verhindern können.
  4. 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.
  5. 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.


Header von tara hunt, CC BY 2.0

Das Update auf MariaDB 10.3
Share this