Nach dem ersten Teil vorgestern war gestern nun der zweite Teil des Upgrade-Marathons auf meinem Heimserver angesagt, also das Upgrade von Debian Buster auf Bullseye. Um es gleich vorweg zu nehmen: das lief leider noch etwas holpriger als der erste Teil.
Großes Sorgenkind war dieses Mal MariaDB, wovon bei noch relativ viele andere Dienste abhängen. Dazu muss man noch wissen, dass ich zwei Raspberry Pis habe, die jeweils eine Wetterstation auslesen und die Daten in jeweils eine Datenbank lokal auf dem Raspi speichern. Diese Datenbanken werden dann per Replication sozusagen auf dem Heimserver gespiegelt, das heißt, MariaDB auf dem Heimserver muss gleich zwei Mal als Replication Slave agieren. Eine Replication-Verbindung habe ich dabei sozusagen auf die klassische Weise, also „anonym“ eingerichtet, die zweite mit dem, was die MariaDB-Doku als „connection_name“ bezeichnet und dem Namen „wetterpi“. Und bei genau jener zweiten Verbindung muss irgendwo etwas schiefgegangen sein. Was genau konnte ich auf die Schnelle nicht ermitteln, möglicherweise wurden bei einem der Neustarts im Rahmen des Upgrades inkonsistente Daten geschrieben. Jedenfalls äußerte sich das Problem mit der Fehlermeldung
[ERROR] Failed to open the relay log '/var/log/mysql/mysql-relay-bin-wetterpi.001266' (relay_log_pos 555)
[ERROR] Could not find target log during relay log initialization
[ERROR] Initialized Master_info from 'master-wetterpi.info' failed
[Note] Added new Master_info 'wetterpi' to hash table
[Warning] Reading of some Master_info entries failed
[ERROR] Failed to initialize multi master structures
[ERROR] Aborting
in den Logfiles und der kompletten Weigerung von MariaDB überhaupt zu starten. Nachdem mich Google nicht wirklich weitergebracht hatte, habe ich kurzerhand zum Holzhammer gegriffen und die Dateien multi-master.info sowie relay-log-wetterpi.info aus /var/lib/mysql gelöscht. Damit startete MariaDB tatsächlich wieder und ich konnte – nach einem RESET SLAVE; – zumindest die „normale“ Replikation neu einrichten. Die „wetterpi“-Replikation wollte sich jedoch (noch) nicht wieder einrichten. Nach einigem Hin- und Her-Probieren half dann auch hier letztendlich nur der Holzhammer: ich habe aus /var/lib/mysql alle Dateien mit „wetterpi“ im Dateinamen gelöscht und in MariaDB nochmals RESET SLAVE; ausgeführt. Danach ließen sich dann beide Replikationen ohne weitere Probleme wieder einrichten und in Betrieb nehmen.
Die übrigen Problemchen waren dagegen relativ leicht zu lösen:
- Obwohl ich schon vor dem Upgrade in den Apache-Modulen etwas aufgeräumt hatte, stolperte Apache zunächt über ein falsches PHP-Modul. Ein entsprechendes a2dismod und a2enmod haben das behoben.
- In der proftpd-Konfiguration musste ich die IdentLookups-Option auskommentieren, damit der Daemon wieder startete.
- Baïkal, das ich direkt installiert habe (da es in Debian nicht paketiert ist), lief zuvor noch in einer sehr, sehr alten Version 0.4.6, welche nicht mehr mit PHP7.4, da es irgendwo im Code noch each() verwendete und die Deprecated-Warnung dazu die weitere Ausführung blockierten. Auf die allerneueste Version konnte ich allerdings auch nicht direkt wechseln, weil die wiederum nicht mehr auf PHP7.4 läuft. Also habe ich mir von Github die Version 0.9.1 besorgt und manuell auf diese geupdatet, was problemlos funktionierte.
Damit laufen nun wieder zumindest die notwendigsten Dienste und ich kann mich gleich an den nächsten Upgrade-Schritt wagen.