MariaDB Galera Cluster Recovery
Falsche Verwendung der hier genannten Befehle / Einstellungen kann zum Datenverlust führen! Backups sind grundsätzlich immer sinnvoll, bevor man Daten löscht / synchronisiert.
Ein Mariadb-Cluster kann ganz, oder teilweise ausfallen. Je nach Art des Ausfalls können unterschiedliche Reparatur-Schritte notwendig sein.
Existiert noch ein Cluster, können Nodes wieder eingegliedert werden. Hierfür ist in der Regel ein einfacher Restart der ausgefallenen Nodes ausreichend.
Die zwischenzeitlich angefallenen Daten-Differenzen werden dann neu synchronisiert und der Mariadb-Server anschließend wieder eingebunden.
Diese Anleitung generisch gehalten, weswegen je nach Installationsart (Paket oder Container) Abweichungen nötig sein können.
Galera Cluster prüfen
Auf einem noch funktionierenden Node kann die Cluster-Größe geprüft werden:
SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+Weicht die Menge von der gewünschten Größe ab, müssen die defekten MariaDBs neugestartet werden. In diesem Fall ist alles in Ordnung, 3 von 3 Nodes sind im Cluster.
Cluster komplett neu starten
In manchen Fällen kann das gesamte Cluster gestoppt oder abgestürzt sein. In diesem Fall werden folgende Schritte notwendig:
- letzten aktiven Node mit konsistentem Datenbestand ermitteln
- Cluster von diesem Node aus starten (boostrap)
- die anderen Nodes in den Cluster joinen
letzten aktiven Node ermitteln
Auf allen Servern prüft man den Status mittels State-File:
# SERVER-A
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 00000000-0000-0000-0000-000000000000
seqno: -1
safe_to_bootstrap: 0
# SERVER-B
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 05debef1-9635-4a3d-aade-7b2f7625cace
seqno: 12345
safe_to_bootstrap: 1
# SERVER-C
$ cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 00000000-0000-0000-0000-000000000000
seqno: -1
safe_to_bootstrap: 0Hierbei ist der Punkt safe_to_bootstrap von Relevanz. Der letzte aktive Node (hier Server B) sollte eine 1 eingetragen haben, wodurch bewiesen ist, dass der Datenbestand auf diesem Server der aktuellste ist und ein Neustart sicher ist. Würde der Cluster von einem anderen Server gestartet werden, lüden sich die anderen einen veralteten Stand herunter und Datenverlust droht!
Ansonsten kann der letzte Node auch anhand der höchsten seqno ermittelt werden!
Ist auf keinem der Nodes das Flag gesetzt, ist es sinnvoll in den Log-Dateien (Journal) den letzten aktiven Server zu ermitteln.
Alternativ startet man ein eigenes Cluster auf jedem Server und muss die Daten händisch vergleichen und abwägen (worst-case).
Cluster boostrap
Für einen Boostrap müssen Konfigurationen angepasst werden. In der MariaDB Konfiguration:
# auskommentieren der Node-Adressen
#wsrep_cluster_address="gcomm://10.20.30.1,10.20.30.2,10.20.30.3"
# leere gcom:// setzen
wsrep_cluster_address="gcomm://"Der Start-Parameter von MariaDB muss nun auch angepasst werden:
mysqld --wsrep-new-clusterIn einer Docker-Umgebung kann dies an den Command-Parameter angehängt werden…
Re-Join der anderen Nodes
Die anderen Nodes sollten aufgrund der gesetzten “wsrep_cluster_address”-Einstellung automatisch dem Cluster beitreten. Manchmal können die unterschiedlichen Daten hier für Probleme sorgen. In diesem Fall kann es notwendig sein, die Daten im MySQL-Verzeichnis zu löschen. Nach einem Neustart synchronisiert MariaDB die Daten komplett neu und nach erfolgreichem Kopieren wird der Node integriert.