So richten Sie die synchrone Multi-Master-Replikation von MariaDB Galera mit Debian 10 ein

MariaDB bietet zwei verschiedene Hochverfügbarkeits- (HA) und Clustering-Lösungen an. Die erste ist die standardmäßige MariaDB-Master/Slave-Replikation, die in verschiedenen Topologien hauptsächlich für Lastausgleich, Hochverfügbarkeit und Sicherungszwecke konfiguriert werden kann. Die zweite ist MariaDB Galera, eine synchrone Multi-Master-Clustering-Lösung. Seine Hauptmerkmale sind wie folgt:

• Multi-Master:Alle Knoten in einem Galera-Cluster können sowohl Lese- als auch Schreibvorgänge ausführen, was eine bessere Skalierbarkeit bietet.
• Knoten können einem Cluster automatisch beitreten und werden bei einem Fehler entfernt.
• Die Galera-Replikation ist synchron, was bedeutet, dass Änderungen auf einem Knoten garantiert auf die anderen Knoten angewendet werden. Damit ist theoretisch sichergestellt, dass beim Ausfall eines Knotens keine Daten verloren gehen.

Dieser Leitfaden führt Sie durch die Installation von MariaDB und seine Konfiguration in einem Galera-Cluster. Wir werden drei Debian 10-Knoten zur Demonstration verwenden, obwohl eine beliebige Anzahl (≥3) von Knoten verwendet werden kann. Das Einrichten von zwei Knoten in einem Galera-Cluster ist technisch möglich, bietet jedoch keine Fehlertoleranz, da ein ausgefallener Knoten dazu führt, dass der andere Knoten stoppt.

Anforderungen

• Drei oder mehr Debian 10-Instanzen.
• Zugriff für den Root-Benutzer oder jeden Benutzer mit sudo-Berechtigungen.
• Der $EDITOR Umgebungsvariable gesetzt werden sollte.

HINWEIS: Galera-Cluster können über WAN oder LAN arbeiten. Wenn sich Ihre Knoten ein privates Netzwerk teilen, verwenden Sie gegebenenfalls private IP-Adressen. Andernfalls sollten WAN-Adressen verwendet werden.

Wenn Sie einen sudo-Benutzer verwenden, öffnen und verwenden Sie für die Dauer dieses Setups eine Root-Shell mit:

sudo -s

Schritt 1:Installation von MariaDB

Dieser Schritt sollte auf allen Knoten ausgeführt werden.

Verwenden Sie die folgenden Befehle, um MariaDB, die Galera-Bibliothek und Rsync zu installieren. Letzteres wird von Galera verwendet.

apt updateapt install -y mariadb-server mariadb-client galera-3 rsync

Stellen Sie sicher, dass der MariaDB-Dienst aktiviert ist:

systemctl aktiviert mariadb.service

Sichern Sie Ihre MariaDB-Instanzen mit dem mysql_secure_installation-Skript:

mysql_secure_installation

Beantworten Sie die Fragen wie unten gezeigt und stellen Sie sicher, dass Sie ein starkes Passwort für den MySQL-Root-Benutzer wählen.

Geben Sie das aktuelle Passwort für root ein (Eingabe für keins):Drücken Sie Set root password? [Y/n] yNeues Passwort:your_passwordNeues Passwort erneut eingeben:your_passwordAnonyme Benutzer entfernen? [J/n] yRoot-Anmeldung aus der Ferne verbieten? [J/n] yTestdatenbank und Zugriff darauf entfernen? [J/n] yBerechtigungstabellen jetzt neu laden? [Y/n] yAlles erledigt! Wenn Sie alle oben genannten Schritte durchgeführt haben, sollte Ihre MariaDB-Installation jetzt sicher sein.

Schritt 2:MariaDB konfigurieren

Dieser Schritt sollte auf allen Knoten ausgeführt werden.

Beenden Sie den MariaDB-Dienst auf allen Knoten:

systemctl stop mariadb.service

Standardmäßig lauscht der MariaDB-Daemon nur auf localhost auf Verbindungen. Damit der Cluster funktioniert, sollte dies auf eine extern zugängliche Adresse geändert werden. Bearbeiten Sie dazu die Optionsdatei /etc/mysql/mariadb.conf.d/50-server.cnf:

$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf

Suchen Sie die folgende Zeile:

Bindungsadresse =127.0.0.1

Wenn Sie ein privates Netzwerk für den Cluster verwenden und MariaDB nicht anderen Netzwerken (z. B. WAN) zugänglich machen möchten, geben Sie die lokale IPv4-Adresse für jeden Knoten an. Verwenden Sie andernfalls 0.0.0.0, das MariaDB anweist, auf allen Schnittstellen zu lauschen. Zum Beispiel:

Bindeadresse =0.0.0.0

Speichern Sie die Änderung und beenden Sie Ihren Texteditor.

Wir werden jetzt Cluster-bezogene Optionen konfigurieren. Erstellen Sie eine neue Optionsdatei:

$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf

Tragen Sie die folgende sinnvolle Konfiguration in die Datei ein und ersetzen Sie die IP-Adressen. Es sollte auf allen Knoten identisch sein.

[galera]
wsrep_on =on wsrep_provider =/lib/galera/libgalera_smm.so wsrep_cluster_address =gcomm://192.0.2.1,192.0.2.2,192.0.2.3 wsrep_cluster_name =galera_cluster_0 default_storage_engine =InnoDB innodb_double_autoinc_lock_lock =1 binlog_format =ZEILE

• wsrep_on =on aktiviert die Write-Set-Replikation, die zugrunde liegende Funktionalität, die von Galera verwendet wird.
• wsrep_provider gibt den Pfad zur Galera-Bibliothek an. Es wird vom galera-3-Paket unter /lib/galera/libgalera_smm.so auf Debian 10 bereitgestellt.
• wsrep_cluster_address sollte mindestens eine Adresse eines anderen Clustermitglieds enthalten. Es wird empfohlen, alle Mitglieder des Clusters aufzulisten. Es ist keine besondere Reihenfolge erforderlich.
• wsrep_cluster_name sollte für den Cluster eindeutig und auf allen Knoten desselben Galera-Clusters identisch sein.
• Die verbleibenden Optionen sind erforderlich, damit Galera richtig funktioniert und sollten nicht geändert werden.

Schritt 3:Bootstrapping des Clusters

Stellen Sie sicher, dass MariaDB auf allen Knoten gestoppt/inaktiv ist, bevor Sie fortfahren:

systemctl status mariadb.service

Um den Cluster zu starten, muss er zunächst von einem Knoten erstellt werden. Unter Debian 10 kann dies mit dem Skript galera_new_cluster erfolgen. Das Skript sollte nur auf einem Knoten ausgeführt werden und nur einmal, um den Cluster zu initialisieren.

galera_new_cluster

Dadurch wird MariaDB auf dem aktuellen Knoten gestartet. Stellen Sie sicher, dass es läuft mit:

systemctl status mariadb.service

Starten Sie dann MariaDB auf den anderen Knoten mit:

systemctl startet mariadb.service

Der Cluster sollte jetzt betriebsbereit sein.

Schritt 4:Testen

Um sicherzustellen, dass der Cluster wie vorgesehen funktioniert, wählen Sie einen beliebigen Knoten aus und melden Sie sich bei MariaDB an:

mysql -u root -p

Setzen Sie die folgende Anweisung ab, um eine Datenbank zu erstellen:

> CREATE DATABASE test0;> \q

Suchen Sie dann auf allen anderen Knoten nach dieser neuen Datenbank:

mysql -u root -p -e "DATENBANKEN ANZEIGEN;"

Der obige Befehl sollte eine Liste zurückgeben, die test0:

enthält

+--------------------+| Datenbank |+--------------------+| Informationsschema || MySQL || Leistungsschema || test0 |+--------------------+

Möglicherweise möchten Sie gründlicher testen, indem Sie von jedem Knoten in den Cluster schreiben. Wenn Sie mit dem Testen zufrieden sind, bereinigen Sie alle nicht benötigten Datenbanken aus dem Cluster. Jeder Knoten kann verwendet werden.

mysql -u root -p -e "DROP DATABASE test0;"

Schritt 5:Tipps zur Fehlerbehebung

Verwenden Sie die folgende Abfrage, um Informationen zum aktuellen Status des Knotens/Clusters anzuzeigen:

mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_REPL_LATENCY','WSREP_EVS_DELAYED','WSREP_READY');" 

 Ein fehlerfreier 3-Knoten-Cluster sollte Folgendes zurückgeben:
 
+----------------------+----------------+| VARIABLE_NAME | VARIABLE_VALUE |+---------------------+----------------+| WSREP_CLUSTER_SIZE | 3 || WSREP_CLUSTER_STATUS | Primär || WSREP_EVS_DELAYED | || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT | Synchronisiert || WSREP_BEREIT | EIN |+-----------------------------------+----------------+ 
 
WSREP_CLUSTER_SIZE stellt die aktuelle Anzahl von Knoten in der Cluster-Komponente dar.
 
WSREP_CLUSTER_STATUS repräsentiert den Zustand der Cluster-Komponente und nicht des Clusters als Ganzes.
 
WSREP_EVS_DELAYED zeigt eine Liste von Knoten, die verzögert sind. Von gesunden Clustern wird ein leerer Wert erwartet.
 
WSREP_EVS_REPL_LATENCY zeigt die Replikationslatenz im Format min/avg/max/stddev/samplesize. Die Werte werden in Sekunden angezeigt. Sehr hohe Latenzen können zu Leistungseinbußen führen. 
 
WSREP_LOCAL_STATE_COMMENT zeigt den aktuellen Knotenstatus.
 
WSREP_READY gibt an, ob der Knoten Abfragen annehmen kann.
 
 

 Wenn ein Knoten in einem 3-Knoten-Cluster die Konnektivität verliert, wird der Cluster in eine primäre Komponente unterteilt, die aus 2 Knoten und einer nicht-primären Komponente besteht. Die Primärkomponente ist von dem Ausfall nicht betroffen und arbeitet normal weiter. Aus der Perspektive der nicht primären Komponente würde die oben gezeigte Abfrage Folgendes zurückgeben:
 
+----------------------+----------------- -------------------------------------------------- -------------------------------------------------- ----------+| VARIABLE_NAME | VARIABLE_WERT |+---------------------+------------------- -------------------------------------------------- -------------------------------------------------- ---------+| WSREP_CLUSTER_SIZE | 1 || WSREP_CLUSTER_STATUS | Nicht-Primär || WSREP_EVS_DELAYED | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907:tcp://192.0.2.1:4567:3,a421be89-fe7d-11e9-a91e-7e62f7562e58:tcp://192.0.2.3:4567:2 || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT | Initialisiert || WSREP_BEREIT | AUS |+-----------------------------------+------------------- -------------------------------------------------- -------------------------------------------------- ---------+
 

 Beachten Sie den Wert WSREP_EVS_DELAYED, der auf Verbindungsprobleme mit den anderen Knoten hinweist.
 

 Auf primären Komponentenknoten gibt dieselbe Abfrage Folgendes zurück:
 
+----------------------+----------------- ----------------------------------------------+| VARIABLE_NAME | VARIABLE_WERT |+---------------------+------------------- ---------------------------------------------+| WSREP_CLUSTER_SIZE | 2 || WSREP_CLUSTER_STATUS | Primär || WSREP_EVS_DELAYED | a2217526-fe7d-11e9-8692-1f2f0cdb403d:tcp://192.0.2.2:4567:2 || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT | Synchronisiert || WSREP_BEREIT | EIN |+-----------------------------------+------------------- ---------------------------------------------+
 

 Zur Wiederherstellung nach dem Ausfall eines einzelnen Knotens ist kein manueller Eingriff erforderlich. Wenn sich der ausgefallene Knoten wieder mit dem Cluster verbindet, wird er automatisch mit dem Cluster synchronisiert.
 
Weitere Informationen
 

 Für erweiterte Konfigurationsoptionen siehe Galera Cluster System Variables.