Nach einer Umstellung der Datenbank-Kollation bei Linuxspicker auf utf8mb4_bin gab es plötzlich 404 Fehler bei einigen, aber nicht allen Stichworten in Verbindung mit dem Textpattern-Plugin tru_tags.

Bei meinem virtuellen Server (VPS) von Strato fingen vor mehreren Jahren massiv Fehlermeldungen bei Cronjobs a la /bin/sh: 1: Cannot fork bzw. can't fork an, die auf hohe Load Averages von mehr als 100 zurückgingen und komplette Aussetzer nach sich zogen, die teils nur mit Neustarts zu beheben waren.

Mit Systemd werden abgestürzte Dienste neu gestartet und das System sollte eigentlich ohne großartige Überwachung laufen. Bei manchen kritischen Diensten lohnt es sich aber trotzdem separat ein Monitoring laufen zu lassen, um eventuell präventiv Maßnahmen zu ergreifen. Dafür bietet sich immer noch monit an.

Der Morgen begann heute mit Schreckensmeldungen vom Datenbankserver. Dieser startete dauernd neu und konnte sich einfach nicht beruhigen. Fehlermeldungen a la [ERROR] InnoDB: Failed to read page 12 from file './mysql/innodb_index_stats.ibd': Page read from tablespace is corrupted ließen die mysql-error.log auf mehrere Megabyte ansteigen.

In einer schwachen Sekunde zog ich ein Upgrade von Mariadb 10.5.11 auf 10.6.3 durch. Die Knowledge-Base machte Hoffnung mit der Aussage

On most servers upgrading from 10.5 should be painless.

Im MySQL bzw. MariaDB kommen verschiedene Datenbankengines mit ihren Vor- und Nachteilen zum Einsatz. Der frühere Standard MyISAM ist praktisch bereits überall durch InnoDB ersetzt worden. Bei MySQL ist InnoDB seit Version 5.5 Standard, bei MariaDB seit Version 10.2. InnoDB hat durch die Absturzsicherheit klare Vorteile.