Letztens wollten wir einen neuen Slave-Datenbankserver f\u00fcr 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.<\/p>\n\n\n\n
Zun\u00e4chst erstellten wir ein Dump mit den Master-Koordinaten:<\/p>\n\n\n\n
mysqldump -F –master-data –all-databases<\/p>\n\n\n\n
und spielten diesen auf dem neuen Server ein. Anschliessend noch Hostname, Username und Passwort f\u00fcr die Replikationsverbindung gesetzt und nach einem „START SLAVE;“ lief die Replikation zun\u00e4chst.<\/p>\n\n\n\n
Nach einiger Zeit meldete sich jedoch das Monitoring mit einer Warnung,dass die Replikation h\u00e4ngt. Ein „SHOW SLAVE STATUS;“ zeigte folgende Fehlermeldung:<\/p>\n\n\n\n
error reconnecting to master ‚replicant@192.168.10.100:3306‘ –
retry-time: 60 maximum-retries: 86400 message:<\/p>\n\n\n\n
Wie man sieht, ist die Fehlermeldung leer. Das ist nicht besonders hilfreich. Auch im Log unter h\u00f6chstem Loglevel („SET GLOBAL log_warnings=9“) ist nur einmalig folgendes zu sehen:<\/p>\n\n\n\n
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<\/p>\n\n\n\n
„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.<\/p>\n\n\n\n
Ein Packet-Dump auf Netzwerkebene zeigt hingegen durchaus min\u00fctliche Verbindungsversuche. Dabei war folgende Kommunikation auff\u00e4llig:<\/p>\n\n\n\n
SLAVE: SET NAMES utf8mb4
MASTER: Unknown character set: ‚utf8mb4‘<\/p>\n\n\n\n
Danach bricht der Slave die Verbindung ab.Tats\u00e4chlich 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\u00fchrte jedoch nicht zum Erfolg, erneute Dumps der Netzwerkkommunikation zeigten denselben Fehler. Es stellte sich heraus, dass das nachtr\u00e4glich 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\u00dfend war der Fehler behoben.<\/p>\n\n\n\n
Hier scheint es noch einige Ungereimtheiten in MariaDB 10.3 zu geben,insbesondere die nichtssagenden Fehlermeldungen sowie das Fehlen von Logeintr\u00e4gen, die bei der Suche nach der Fehlerursache helfen k\u00f6nnten,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.<\/p>\n\n\n\n
Wir werden einen entsprechenden Bugreport dazu an das MariaDB-Devteam schreiben.<\/p>\n\n\n\n
![ttps:\/\/labs.mysql.com\/common\/logos\/mysql-logo.svg<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Letztens wollten wir einen neuen Slave-Datenbankserver f\u00fcr 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 …<\/p>\n","protected":false},"author":1,"featured_media":188,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,4],"tags":[37,39,35,36,28],"_links":{"self":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts\/187"}],"collection":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/comments?post=187"}],"version-history":[{"count":3,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts\/187\/revisions"}],"predecessor-version":[{"id":191,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/posts\/187\/revisions\/191"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/media\/188"}],"wp:attachment":[{"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/media?parent=187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/categories?post=187"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vautron.de\/blog\/wp-json\/wp\/v2\/tags?post=187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"ttps:\/\/labs.mysql.com\/common\/logos\/mysql-logo.svg\"){kind=link}