Springe zum Inhalt

Beim Hochfahren eines MariaDB-Galera-Cluster-Nodes muss dieser erst einmal synchronisiert werden. Standardmäßig sucht sich der Node einen anderen bereits synchronisierten Node des Clusters aus, von dem er anschließend synchronisiert. Bei der Synchronisation ist der Datenlieferant für die Zeit der Synchronisation komplett gesperrt und kann von Clients nicht verwendet werden. Um das zu verhindern kann ein eigener Node aufgesetzt werden, auf den keine Clientprogramme zugreifen. Dieser Node wird dann als bevorzugte Quelle für die Synchronisation bei allen anderen Nodes eingestellt.

In der MariaDB-Konfiguration muss dazu folgendes angegeben werden:

wsrep_sst_donor = "donornode,"

Zu beachten ist, dass als Name der Nodename und nicht der Hostname des bevorzugten Datenlieferanten angegeben werden muss. Dass Kommata am Schluß ist kein Schreibfehler, sondern sorgt dafür, dass bei nicht verfügbarem Datenlieferant dass Standardverfahren angewendet und ein zufälliger Node für die Synchronisation ausgewählt wird.

Bei der anschließenden Synchronisation des Nodes ist die Auswahl des bevorzugten Nodes auch im Logfile zu erkennen:

WSREP: Member 3.0 (node5) requested state transfer from 'node0,'. Selected 2.0 (node0)(SYNCED) as donor.
WSREP: 2.0 (node0): State transfer to 3.0 (node5) complete
WSREP: Member 2.0 (node0) synced with group.
WSREP: 3.0 (node5): State transfer from 2.0 (node0) complete.
WSREP: Member 3.0 (node5) synced with group.
WSREP: Synchronized with group, ready for connections

Im vorliegenden Beispiel war node0 as bevorzugter Node für die Synchronisierung eingestellt.

Heute bin ich gleich zwei Mal über das Python-Modul Paramiko gestolpert. In der MySQL-Workbench wird es verwendet, um eine Verbindung über einen SSH-Tunnel herzustellen. Das in der aktuellen MySQL-Workbench ausgelieferte, aber uralte Paramiko versteht sich nicht mehr mit aktuellen OpenSSH-Versionen. Nach einem manuellen Update von Paramiko funktionierte der Verbindungsaufbau dann wieder.

Die zweite Portion Paramiko gab es beim Durchsehen der Backups. Das von mir verwendete Duplicity benutzt ebenfalls Paramiko, wenn Backups auf einem per SSH bzw. SFTP oder SCP erreichbaren Server abgelegt werden sollen. Leider funktioniert SFTP und SCP in Duplicity, und damit implizit Paramiko, aktuell nicht mit einem Backup-Server bei Hetzner. Eine Lösung habe ich bisher leider nicht gefunden.

Nach einem aktuellen Update konnte HHVM auf einmal keine Verbindung mehr zu MySQL bzw. MariaDB aufnehmen. Grund ist der, dass der MySQL-Socket nun wohl unter /tmp/mysql.sock gesucht wird, wo er nicht liegt. Unter Debian liegt er vielmehr unter /var/run/mysqld/mysqld.sock. In der /etc/hhvm/server.ini ist daher folgende Einstellung einzutragen:

hhvm.mysql.socket = /var/run/mysqld/mysqld.sock

Nach einem Neustart von HHVM funktionierts dann auch wieder mit HHVM und MySQL über den Socket.

Beim Einsatz von MariaDB kann es vorkommen, dass PHP5 beim Verbinden mit der Datenbank folgenden Fehler meldet:

mysqli::mysqli(): Headers and client library minor version mismatch.

Die PHP5-Bibliothek, welche für die Anbindung an MariaDB/MySQL zuständig ist, prüft, ob die MariaDB/MySQL-Bibliothek noch die gleiche ist, mit der sie übersetzt wurde. Das ist natürlich nicht mehr der Fall, wenn man die MariaDB/MySQL-Bibliothek auf eine neue Version aktualisiert.

Abhilfe schafft, den mysqlnd-Treiber zu verwenden, was auch das empfohlene Verfahren von MariaDB ist. Dazu muss unter Debian oder Ubuntu das Paket php5-mysqlnd installiert und php5-mysql entfernt werden.

Weitere Informationen: