Letztens wollten wir einen neuen Slave-Datenbankserver für unsereDNS-Datenbank installieren. Dabei war die MySQL-Version des neuen Slaves(Mariadb 10.3, aktuelle Version in Debian Buster) etwas neuer als die des bestehenden Masters (MySQL 5.1.66). Das ist zwar keine optimale Konstellation, aber sollte dennoch funktionieren.
Zunächst erstellten wir ein Dump mit den Master-Koordinaten:
mysqldump -F –master-data –all-databases
und spielten diesen auf dem neuen Server ein. Anschliessend noch Hostname, Username und Passwort für die Replikationsverbindung gesetzt und nach einem „START SLAVE;“ lief die Replikation zunächst.
Nach einiger Zeit meldete sich jedoch das Monitoring mit einer Warnung,dass die Replikation hängt. Ein „SHOW SLAVE STATUS;“ zeigte folgende Fehlermeldung:
error reconnecting to master ‚replicant@192.168.10.100:3306‘ –
retry-time: 60 maximum-retries: 86400 message:
Wie man sieht, ist die Fehlermeldung leer. Das ist nicht besonders hilfreich. Auch im Log unter höchstem Loglevel („SET GLOBAL log_warnings=9“) ist nur einmalig folgendes zu sehen:
2021-02-08 9:47:17 8089 [Note] Slave: received end packet from server,
apparent master shutdown:
2021-02-08 9:47:17 8089 [Note] Slave I/O thread: Failed reading log
event, reconnecting to retry, log ‚mysql-bin.003825‘ at position 1019543
2021-02-08 9:47:17 8089 [ERROR] Slave I/O: error reconnecting to master
‚replicant@192.168.10.100:3306‘ – retry-time: 60 maximum-retries: 86400
message: , Internal MariaDB error code: 0
„Error code: 0“ ist ein deutlicher Hinweis darauf, dass die vorliegende Situation wohl nicht korrekt vom aktuellen Slave behandelt wird. Laut Einstellungen sollte der Slave alle 60 Sekunden einen reconnect versuchen, allerdings gibt es auch hierzu keine Logmeldungen.
Ein Packet-Dump auf Netzwerkebene zeigt hingegen durchaus minütliche Verbindungsversuche. Dabei war folgende Kommunikation auffällig:
SLAVE: SET NAMES utf8mb4
MASTER: Unknown character set: ‚utf8mb4‘
Danach bricht der Slave die Verbindung ab.Tatsächlich kennt der Master diesen Zeichensatz nicht. Gesteuert wird dieser Wert durch die Variable „character_set_server“, also haben wir ein „SET GLOBAL character_set_server=latin1“ abgesetzt und die Replikation erneut gestartet. Dies führte jedoch nicht zum Erfolg, erneute Dumps der Netzwerkkommunikation zeigten denselben Fehler. Es stellte sich heraus, dass das nachträglich Setzen dieser Variable nicht ausreichend ist; sie muss bereits in den Konfigurationsdateien entsprechend mit „character-set-server = latin1“ im „[mysqld]“-Abschnitt beim Start des Servers gesetzt sein. Anschließend war der Fehler behoben.
Hier scheint es noch einige Ungereimtheiten in MariaDB 10.3 zu geben,insbesondere die nichtssagenden Fehlermeldungen sowie das Fehlen von Logeinträgen, die bei der Suche nach der Fehlerursache helfen könnten,sind sicher nicht gewollt. Weiterhin ist es seltsam, dass das Setzen der globalen Variable „character-set-server“ hier keinen Einfluss im laufenden System hat, sondern die Einstellung bereits beim Start-Up gesetzt werden muss.
Wir werden einen entsprechenden Bugreport dazu an das MariaDB-Devteam schreiben.
Bildquelle
https://labs.mysql.com/common/logos/mysql-logo.svg
