MariaDB/Galera cluster: [ERROR] InnoDB Tablespace […] was not found at […]

Bei einem Kunden hatte ich vor ein paar Tagen folgendes Problem:

[…]
Sep 11 00:53:22 NODE0 mysqld[15206]: 2018-09-11 0:53:22 139791907141824 [Note] InnoDB: Starting crash recovery fr
om checkpoint LSN=1624074893677
Sep 11 00:53:22 NODE0 mysqld[15206]: 2018-09-11 0:53:22 139791907141824 [ERROR] InnoDB: Tablespace 72 was not found at ./zabbix/item_discovery.ibd.
Sep 11 00:53:22 NODE0 mysqld[15206]: 2018-09-11 0:53:22 139791907141824 [ERROR] InnoDB: Set innodb_force_recovery=1 to ignore this and to permanently lose all changes to the tablespace.
Sep 11 00:53:22 NODE0 mysqld[15206]: 2018-09-11 0:53:22 139791907141824 [ERROR] InnoDB: Tablespace 111 was not found at ./zabbix/sessions.ibd.
Sep 11 00:53:22 NODE0 mysqld[15206]: 2018-09-11 0:53:22 139791907141824 [ERROR] InnoDB: Tablespace 133 was not found at ./zabbix/trends_uint.ibd.
Sep 11 00:53:22 NODE0 mysqld[15206]: 2018-09-11 0:53:22 139791907141824 [ERROR] InnoDB: Plugin initialization aborted with error Tablespace not found
[…]

Der Kunde aktualisiere in Eigenregie seinen MariaDB Galera cluster und landete, da das Upgrade auf allen Nodes gleichzeitig ausgeführt wurde, bei diesem Problem. Glück im Unglück hatten wir, dass eine der cluster nodes überlebte.

Im Nachhinein konnte ich zwei potentielle Ursachen für das Problem ausmachen:

  • Der Speicherplatz auf dem Mountpoint /var/lib/mysql war unzureichend. Leider konnte ich, da das Monitoring zu jenem Zeitpunkt nicht operabel war nicht nachschauen, ob der Kunde eine Speicherplatz-Warnmeldung ignoriert hatte.
  • Die Dateien der fraglichen Datenbank (Zabbix) waren zu jenem Zeitpunkt 64GB gross.

Die MariaDB Galera Cluster Nodes übertragen die Datenbankdateien vom primary node per rsync. Der Kunde hat eine etwas “lange Leitung” – TenG ist hier komplett unbekannt. Die Datenübertragungsgeschwindigkeit zwischen den Nodes bertägt durchschnittlich 34MB/s… Das Übertragen von theoretisch 64GB dauert länger als das Timeout des Kommandos “service mariadb start”.

Die Lösung war, auf allen nicht mehr laufenden Nodes das Verzeichnis /var/lib/mysql zu leeren dafür zu sorgen, dass systemd unendlich auf den Start des Services wartet:

$ sudo systemctl edit mariadb.service
[Service]
TimeoutStartSec = 0

Danach konnte der Service mit

$ sudo systemctl daemon-reload
$ sudo service mysql start

wieder einwandfrei gestartet werden. Der Start von MariaDB dauert nur knapp 35 Minuten :-).

Ich höre gerade: KISS – I was made for lovin’ you

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.