Im Gegensatz zu Standard-MySQL-Servern und MySQL-Clustern ist die Art und Weise, einen MySQL/MariaDB Galera-Cluster zu starten, etwas anders. Galera erfordert, dass Sie einen Knoten in einem Cluster als Referenzpunkt starten, bevor die verbleibenden Knoten sich dem Cluster anschließen und ihn bilden können. Dieser Vorgang wird als Cluster-Bootstrap bezeichnet. Bootstrapping ist ein erster Schritt, um einen Datenbankknoten als primäre Komponente einzuführen, bevor andere ihn als Referenzpunkt zum Synchronisieren von Daten sehen.
Wie funktioniert es?
Wenn Galera mit dem Bootstrap-Befehl auf einem Knoten startet, erreicht dieser bestimmte Knoten den primären Zustand (überprüfen Sie den Wert von wsrep_cluster_status). Die verbleibenden Knoten benötigen nur einen normalen Startbefehl und sie suchen automatisch nach vorhandener primärer Komponente (PC) im Cluster und verbinden sich, um einen Cluster zu bilden. Die Datensynchronisierung erfolgt dann entweder durch inkrementelle Zustandsübertragung (IST) oder Momentaufnahme-Zustandsübertragung (SST) zwischen dem Joiner und dem Spender.
Grundsätzlich sollten Sie den Cluster also nur booten, wenn Sie einen neuen Cluster starten möchten oder wenn sich kein anderer Knoten im Cluster im Zustand PRIMARY befindet. Bei der Auswahl der zu ergreifenden Maßnahme sollte sorgfältig vorgegangen werden, da es sonst zu Split-Clustern oder Datenverlust kommen kann.
Die folgenden Beispielszenarien veranschaulichen, wann ein Cluster mit drei Knoten basierend auf dem Knotenstatus (wsrep_local_state_comment) und dem Clusterstatus (wsrep_cluster_status) gebootet werden sollte:
| Bundesstaat Galera | Bootstrap-Flow |
|---|---|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
Wie starte ich Galera Cluster?
Die 3 Galera-Anbieter verwenden unterschiedliche Bootstrapping-Befehle (basierend auf der neuesten Version der Software). Führen Sie auf dem ersten Knoten Folgendes aus:
-
MySQL Galera-Cluster (Codership):
$ service mysql bootstrap # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line -
Percona XtraDB-Cluster (Percona):
$ service mysql bootstrap-pxc # sysvinit $ systemctl start [email protected] # systemd -
MariaDB Galera-Cluster (MariaDB):
$ service mysql bootstrap # sysvinit $ service mysql start --wsrep-new-cluster # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
Der obige Befehl ist nur ein Wrapper und startet die MySQL-Instanz auf diesem Knoten mit gcomm:// als Variable wsrep_cluster_address. Sie können die Variablen in my.cnf auch manuell definieren und den standardmäßigen Start-/Neustartbefehl ausführen. Vergessen Sie jedoch nicht, wsrep_cluster_address wieder so zu ändern, dass sie nach dem Start die Adressen aller Knoten enthält.
Wenn der erste Knoten aktiv ist, führen Sie den folgenden Befehl auf den nachfolgenden Knoten aus:
$ service mysql start
$ systemctl start mysqlDer neue Knoten stellt eine Verbindung zu den Clustermitgliedern her, wie durch den Parameter wsrep_cluster_address definiert. Es ruft jetzt automatisch die Cluster-Karte ab, verbindet sich mit den restlichen Knoten und bildet einen Cluster.
Warnung:Verwenden Sie niemals Bootstrap, wenn Sie einen Knoten erneut mit einem vorhandenen Cluster verbinden möchten, und führen Sie Bootstrap NIEMALS auf mehr als einem Knoten aus.
Safe-to-Bootstrap-Flag
Galera ab Version 3.19 enthält ein neues Flag namens „safe_to_bootstrap“ in grastate.dat. Dieses Flag erleichtert die Entscheidung und verhindert unsichere Entscheidungen, indem es die Reihenfolge verfolgt, in der Knoten heruntergefahren werden. Der zuletzt heruntergefahrene Knoten wird als „Safe-to-Bootstrap“ gekennzeichnet. Alle anderen Knoten werden als unsicher zum Bootstrap markiert.
Wenn Sie sich den Inhalt von grastate.dat (standardmäßig unter MySQL datadir) ansehen, sollten Sie das Flag in der letzten Zeile bemerken:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: 2575
safe_to_bootstrap: 0Beim Bootstrapping des neuen Clusters weigert sich Galera, den ersten Knoten zu starten, der als unsicher für das Bootstrapping markiert wurde. Sie werden die folgende Meldung in den Protokollen sehen:
„Es ist möglicherweise nicht sicher, den Cluster von diesem Knoten aus zu booten. Es war nicht das letzte, das den Cluster verlassen hat, und enthält möglicherweise nicht alle Updates.
Um Cluster-Bootstrap mit diesem Knoten zu erzwingen, bearbeiten Sie die Datei grastate.dat manuell und setzen Sie safe_to_bootstrap auf 1 .“
Im Falle eines unsauberen Herunterfahrens oder eines harten Absturzes haben alle Knoten „safe_to_bootstrap:0“, also müssen wir die InnoDB-Speicher-Engine konsultieren, um festzustellen, welcher Knoten die letzte Transaktion im Cluster festgeschrieben hat. Dies kann erreicht werden, indem mysqld mit der Variable „--wsrep-recover“ auf jedem der Knoten gestartet wird, was eine Ausgabe wie diese erzeugt:
$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...Die Nummer nach der UUID-Zeichenfolge in der Zeile „Wiederhergestellte Position“ ist diejenige, nach der gesucht werden muss. Wählen Sie den Knoten mit der höchsten Nummer aus und bearbeiten Sie seine grastate.dat, um „safe_to_bootstrap:1“ festzulegen, wie im folgenden Beispiel gezeigt:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: -1
safe_to_bootstrap: 1Sie können dann den Standard-Bootstrap-Befehl auf dem ausgewählten Knoten ausführen.
Was ist, wenn die Knoten divergiert sind?
Knoten können unter Umständen voneinander abgewichen sein. Der Status aller Knoten kann aufgrund einer Netzwerkaufteilung zwischen Knoten, eines Cluster-Absturzes oder wenn Galera bei der Bestimmung der primären Komponente auf eine Ausnahme stößt, zu „Nicht-Primär“ werden. Sie müssen dann einen Knoten auswählen und ihn zu einer primären Komponente hochstufen.
Um festzustellen, welcher Knoten gebootet werden muss, vergleichen Sie den wsrep_last_committed-Wert auf allen DB-Knoten:
node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10032 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10348 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 997 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+Von den obigen Ausgaben hat node2 die aktuellsten Daten. In diesem Fall sind alle Galera-Knoten bereits gestartet, sodass Sie den Cluster nicht unbedingt erneut booten müssen. Wir müssen nur node2 zu einer primären Komponente machen:
node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";Die verbleibenden Knoten verbinden sich dann erneut mit der primären Komponente (Knoten2) und synchronisieren ihre Daten basierend auf diesem Knoten erneut.
Wenn Sie ClusterControl verwenden (kostenlos testen), können Sie wsrep_last_committed und wsrep_cluster_status direkt aus der ClusterControl> Übersicht ermitteln Seite:
Oder von ClusterControl> Leistung> DB-Status Seite:
