TOC

So konfigurieren Sie einen Galera-Cluster mit MariaDB 10.1 auf Ubuntu 16.04-Servern

Einführung

Durch Clustering wird Ihre Datenbank durch die Verteilung von Änderungen auf verschiedene Server mit hoher Verfügbarkeit versehen. Für den Fall, dass eine der Instanzen ausfällt, stehen andere Instanzen schnell zur Verfügung, um den Betrieb fortzusetzen.

Cluster gibt es in zwei allgemeinen Konfigurationen: Aktiv-Passiv und Aktiv-Aktiv. In Aktiv-Passiv-Clustern werden alle Schreibvorgänge auf einem einzelnen aktiven Server ausgeführt und dann auf einen oder mehrere passive Server kopiert, die nur bei einem Ausfall eines aktiven Servers die Funktion übernehmen können. Einige Aktiv-Passiv-Cluster erlauben auch SELECT-Operationen an passiven Knoten. In einem Aktiv-Aktiv-Cluster ist jeder Knoten schreib- und lesbar, und eine an einem vorgenommene Änderung wird für alle repliziert.

In diesem Handbuch konfigurieren wir einen Aktiv-Aktiv-MariaDB-Galera-Cluster. Zu Demonstrationszwecken konfigurieren und testen wir drei Knoten, den kleinsten konfigurierbaren Cluster.

Voraussetzungen

Um mitzukommen, benötigen Sie:

Sobald alle diese Voraussetzungen erfüllt sind, können Sie MariaDB installieren.

[[Schritt-1 - Hinzufügen der Mariadb-10-1-Repositorys zu allen Servern]] == Schritt 1 - Hinzufügen der MariaDB 10.1-Repositorys zu allen Servern

MariaDB 10.1 ist nicht in den Standard-Ubuntu-Repositorys enthalten. Daher fügen wir zunächst allen drei Servern das externe Ubuntu-Repository hinzu, das vom MariaDB-Projekt verwaltet wird.

[.note] #Note: MariaDB ist ein angesehener Anbieter, aber nicht alle externen Repositorys sind zuverlässig. Stellen Sie sicher, dass Sie nur von vertrauenswürdigen Quellen installieren.
#

Zuerst fügen wir den MariaDB-Repository-Schlüssel mit dem Befehlapt-keyhinzu, mit dem apt überprüft, ob das Paket authentisch ist. 

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

Sobald wir den vertrauenswürdigen Schlüssel in der Datenbank haben, können wir das Repository hinzufügen. Danach müssen wirapt-get update ausführen, um Paketmanifeste aus dem neuen Repository aufzunehmen: 

sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'
sudo apt-get update

[.note] #Note: Sie müssen "update" ausführen, nachdem Sie das Repository hinzugefügt haben. Andernfalls installieren Sie Version 10.0 von den Ubuntu-Paketen, die das Galera-Paket nicht enthalten.
#

Sobald die Repositorys auf allen drei Servern aktualisiert wurden, können Sie MariaDB installieren. Eine Sache, die Sie bei MariaDB beachten sollten, ist, dass es als Drop-In-Ersatz für MySQL entstanden ist. In vielen Konfigurationsdateien und Startskripten werden alsomysql stattmariadb angezeigt. Aus Gründen der Konsistenz verwenden wir in diesem Handbuchmysql, wo beides funktionieren könnte.

[[Schritt 2 - Installation von Mariadb auf allen Servern] == Schritt 2 - Installation von MariaDB auf allen Servern

Ab Version 10.1 werden die Pakete MariaDB Server und MariaDB Galera Server kombiniert. Durch die Installation von "Mariadb-Server" werden Galera und mehrere Abhängigkeiten automatisch installiert: 

sudo apt-get install mariadb-server

Während der Installation werden Sie aufgefordert, ein Kennwort für den MariaDB-Administrator festzulegen. Unabhängig von Ihrer Auswahl wird dieses Root-Kennwort mit dem Kennwort des ersten Knotens überschrieben, sobald die Replikation beginnt.

Wir sollten über alle erforderlichen Komponenten verfügen, um mit der Konfiguration des Clusters zu beginnen. Da wir uns jedoch in späteren Schritten aufrsync verlassen, stellen wir sicher, dass er installiert ist. 

sudo apt-get install rsync

Dies bestätigt, dass die neueste Version vonrsync bereits verfügbar ist, oder fordert Sie auf, sie zu aktualisieren oder zu installieren.

Sobald wir MariaDB auf jedem der drei Server installiert haben, können wir mit der Konfiguration beginnen.

[[Schritt 3 - Konfigurieren des ersten Knotens]] == Schritt 3 - Konfigurieren des ersten Knotens

Jeder Knoten im Cluster muss nahezu identisch konfiguriert sein. Aus diesem Grund nehmen wir die gesamte Konfiguration auf unserem ersten Computer vor und kopieren sie dann auf die anderen Knoten.

Standardmäßig ist MariaDB so konfiguriert, dass das Verzeichnis/etc/mysql/conf.düberprüft wird, um zusätzliche Konfigurationseinstellungen für das Ende in.cnf zu erhalten. In diesem Verzeichnis erstellen wir eine Datei mit all unseren clusterspezifischen Anweisungen: 

sudo nano /etc/mysql/conf.d/galera.cnf

Kopieren Sie die folgende Konfiguration und fügen Sie sie in die Datei ein. Sie müssen die rot hervorgehobenen Einstellungen ändern. Im Folgenden wird erläutert, was die einzelnen Abschnitte bedeuten.

/etc/mysql/conf.d/galera.cnf

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://first_ip,second_ip,third_ip"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"

  • The first section ändert oder bestätigt die MariaDB / MySQL-Einstellungen erneut, damit der Cluster ordnungsgemäß funktioniert. Beispielsweise funktioniert Galera Cluster nicht mit MyISAM oder ähnlichen nicht-transaktionalen Speicher-Engines, undmysqld dürfen nicht an die IP-Adresse von localhost gebunden sein. Weitere Informationen zu den Einstellungen finden Sie in den Galera Clustersystem configuration page.

  • The “Galera Provider Configuration” section konfiguriert die MariaDB-Komponenten, die eine WriteSet-Replikations-API bereitstellen. Dies bedeutet in unserem Fall Galera, da Galera ein wsrep-Anbieter (WriteSet Replication) ist. Wir geben die allgemeinen Parameter an, um die anfängliche Replikationsumgebung zu konfigurieren. Dies erfordert keine Anpassung, aber Sie können mehr überGalera configuration options erfahren.

  • The “Galera Cluster Configuration” section definiert den Cluster, identifiziert die Clustermitglieder anhand der IP-Adresse oder des auflösbaren Domänennamens und erstellt einen Namen für den Cluster, um sicherzustellen, dass die Mitglieder der richtigen Gruppe beitreten. Sie könnenwsrep_cluster_name in etwas aussagekräftigeres alstest_cluster ändern oder unverändert lassen, aber Sie aktualisierenmustwsrep_cluster_address mit den Adressen Ihrer drei Server. Wenn Ihre Server über private IP-Adressen verfügen, verwenden Sie diese hier.

  • The “Galera Synchronization Configuration” section definiert, wie der Cluster Daten zwischen Mitgliedern kommuniziert und synchronisiert. Dies wird nur für die Statusübertragung verwendet, die erfolgt, wenn ein Knoten online geschaltet wird. Für unser erstes Setup verwenden wirrsync, da es allgemein verfügbar ist und das tut, was wir jetzt brauchen.

  • The “Galera Node Configuration” section verdeutlicht die IP-Adresse und den Namen des aktuellen Servers. Dies ist hilfreich, wenn Sie versuchen, Probleme in Protokollen zu diagnostizieren und die einzelnen Server auf verschiedene Arten zu referenzieren. Diewsrep_node_address müssen mit der Adresse des Computers übereinstimmen, auf dem Sie sich befinden. Sie können jedoch einen beliebigen Namen auswählen, um den Knoten in Protokolldateien besser identifizieren zu können.

Wenn Sie mit Ihrer Cluster-Konfigurationsdatei zufrieden sind, kopieren Sie den Inhalt in Ihre Zwischenablage, speichern und schließen Sie die Datei.

[[Schritt 4 - Konfigurieren der verbleibenden Knoten]] == Schritt 4 - Konfigurieren der verbleibenden Knoten

Öffnen Sie auf jedem der verbleibenden Knoten die Konfigurationsdatei: 

sudo nano /etc/mysql/conf.d/galera.cnf

Fügen Sie die Konfiguration ein, die Sie vom ersten Knoten kopiert haben, und aktualisieren Sie dann die "Galera-Knotenkonfiguration", um die IP-Adresse oder den auflösbaren Domänennamen für den bestimmten Knoten zu verwenden, den Sie einrichten. Aktualisieren Sie abschließend den Namen, den Sie festlegen können, um den Knoten in Ihren Protokolldateien zu identifizieren:

/etc/mysql/conf.d/galera.cnf

. . .
# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"
. . .

Speichern und beenden Sie die Datei auf jedem Server. Wir sind fast bereit, den Cluster aufzurufen, aber bevor wir dies tun, möchten wir sicherstellen, dass die entsprechenden Ports geöffnet sind.

[[Schritt 5 - Öffnen der Firewall auf jedem Server]] == Schritt 5 - Öffnen der Firewall auf jedem Server

Überprüfen Sie auf jedem Server den Status der Firewall: 

sudo ufw status

In diesem Fall ist nur SSH erlaubt durch: 

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

Da in diesem Fall nur SSH-Datenverkehr zulässig ist, müssen Regeln für MySQL- und Galera-Datenverkehr hinzugefügt werden. Wenn wir versuchen, den Cluster zu starten, schlagen wir aufgrund von Firewall-Regeln fehl.

Galera kann vier Ports nutzen:

  • 3306 Für MySQL-Client-Verbindungen und Status-Snapshot-Übertragung, die die mysqldump-Methode verwenden.

  • 4567 Für den Galera Cluster-Replikationsverkehr verwendet die Multicast-Replikation sowohl UDP-Transport als auch TCP an diesem Port.

  • 4568 Für inkrementelle Statusübertragung.

  • 4444 Für alle anderen Status-Snapshot-Übertragungen.

In unserem Beispiel öffnen wir alle vier Ports, während wir unsere Einrichtung vornehmen. Sobald wir bestätigt haben, dass die Replikation funktioniert, möchten wir alle Ports schließen, die wir nicht tatsächlich verwenden, und den Datenverkehr auf nur Server im Cluster beschränken.

Öffnen Sie die Ports mit dem folgenden Befehl: 

sudo ufw allow 3306,4567,4568,4444/tcp
sudo ufw allow 4567/udp

[.note] #Note: Abhängig davon, was sonst noch auf Ihren Servern ausgeführt wird, möchten Sie möglicherweise den Zugriff sofort einschränken. Die Anleitung zuUFW Essentials: Common Firewall Rules and Commandskann dabei helfen.
#

[[Schritt-6 - Starten des Clusters]] == Schritt 6 - Starten des Clusters

Zunächst müssen wir den laufenden MariaDB-Dienst stoppen, damit unser Cluster online geschaltet werden kann.

Beenden Sie MariaDB auf allen drei Servern:

Verwenden Sie den folgenden Befehl auf allen drei Servern, um mysql zu stoppen, damit wir sie in einem Cluster sichern können: 

sudo systemctl stop mysql

systemctl zeigt nicht das Ergebnis aller Serviceverwaltungsbefehle an. Um sicherzustellen, dass dies erfolgreich war, verwenden wir den folgenden Befehl: 

sudo systemctl status mysql

Wenn die letzte Zeile wie folgt aussieht, war der Befehl erfolgreich. 

Output . . .
Aug 19 02:55:15 galera-01 systemd[1]: Stopped MariaDB database server.

Sobald wirmysql auf allen Servern heruntergefahren haben, können wir fortfahren.

Rufe den ersten Knoten auf:

Zum Aufrufen des ersten Knotens benötigen wir ein spezielles Startskript. So wie wir unseren Cluster konfiguriert haben, versucht jeder Knoten, der online geht, eine Verbindung zu mindestens einem anderen Knoten herzustellen, der in seinergalera.cnf-Datei angegeben ist, um seinen Ausgangszustand zu erhalten. Ohne die Verwendung des Skriptsgalera_new_cluster, mit dem systemd den Parameter--wsrep-new-cluster übergeben kann, würde ein normalersystemctl start mysql fehlschlagen, da keine Knoten ausgeführt werden, mit denen der erste Knoten eine Verbindung herstellen kann. 

sudo galera_new_cluster

Wenn dieses Skript erfolgreich ausgeführt wurde, wird der Knoten als Teil des Clusters registriert und mit dem folgenden Befehl angezeigt: 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Auf den verbleibenden Knoten können wirmysql normal starten. Sie suchen nach allen Mitgliedern der Cluster-Liste, die online sind. Wenn sie eines finden, treten sie dem Cluster bei.

Rufe den zweiten Knoten auf:

Startmysql: 

sudo systemctl start mysql

Wir sollten feststellen, dass die Clustergröße zunimmt, wenn jeder Knoten online geht: 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

Rufe den dritten Knoten auf:

Startmysql: 

sudo systemctl start mysql

Wenn alles gut funktioniert, sollte die Clustergröße auf drei festgelegt werden: 

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"
Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Zu diesem Zeitpunkt sollte der gesamte Cluster online sein und kommunizieren. Bevor wir die Replikation testen, müssen wir uns jedoch noch um ein weiteres Konfigurationsdetail kümmern.

[[Schritt-7 - Konfigurieren des Debian-Wartungsbenutzers]] == Schritt 7 - Konfigurieren des Debian-Wartungsbenutzers

Gegenwärtig führen die MariaDB-Server von Ubuntu und Debian routinemäßige Wartungsarbeiten durch, z. B. die Protokollrotation als spezieller Wartungsbenutzer. Bei der Installation von MariaDB wurden die Anmeldeinformationen für diesen Benutzer zufällig generiert, in/etc/mysql/debian.cnf gespeichert und in diemysql-Datenbank der MariaDB eingefügt.

Sobald wir unseren Cluster aufgerufen haben, wurde das Kennwort vom ersten Knoten auf die anderen Knoten repliziert, sodass der Wert indebian.cnf nicht mehr mit dem Kennwort in der Datenbank übereinstimmt. Dies bedeutet, dass alles, was das Wartungskonto verwendet, versucht, mit dem Kennwort in der Konfigurationsdatei eine Verbindung zur Datenbank herzustellen, und auf allen Knoten außer dem ersten Knoten fehlschlägt.

Um dies zu korrigieren, kopieren wir diedebian.cnf unseres ersten Knotens auf die verbleibenden Knoten.

Kopieren vom ersten Knoten:

Öffnen Sie diedebian.cnf-Datei mit Ihrem Texteditor: 

sudo nano /etc/mysql/debian.cnf

Die Datei sollte ungefähr so ​​aussehen: 

[client]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Kopieren Sie die Informationen in Ihre Zwischenablage.

Aktualisieren Sie den zweiten Knoten:

Öffnen Sie auf Ihrem zweiten Knoten dieselbe Datei: 

sudo nano /etc/mysql/debian.cnf

Trotz der Warnung oben in der Datei mit der Aufschrift „NICHT BERÜHREN!“ Müssen wir die Änderung vornehmen, damit der Cluster funktioniert. Sie können die aktuellen Informationen sicher löschen und den Inhalt aus der Konfiguration des ersten Knotens einfügen. Sie sollten jetzt genau gleich sein. Speichern und schließen Sie die Datei.

Aktualisieren Sie den dritten Knoten:

Öffnen Sie auf Ihrem dritten Knoten dieselbe Datei: 

sudo nano /etc/mysql/debian.cnf

Löschen Sie die aktuellen Informationen und fügen Sie den Inhalt aus der Konfiguration des ersten Knotens ein. Speichern und schließen Sie die Datei.

Die Nichtübereinstimmung hätte unsere Fähigkeit zum Testen der Replikation nicht beeinträchtigt. Es ist jedoch empfehlenswert, frühzeitig darauf zu achten, um spätere Fehler zu vermeiden.

[.Hinweis]##

Note: Nachdem Sie fertig sind, können Sie testen, ob das Wartungskonto eine Verbindung herstellen kann, indem Sie das Kennwort von den lokalendebian.conf wie folgt eingeben: 

sudo cat /etc/mysql/debian.cnf

Kopieren Sie das Passwort aus der Ausgabe. Stellen Sie dann eine Verbindung zumysql her: 

mysql -u debian-sys-maint -p

Geben Sie an der Eingabeaufforderung das von Ihnen kopierte Kennwort ein. Wenn Sie eine Verbindung herstellen können, ist alles in Ordnung.

Ist dies nicht der Fall, überprüfen Sie, ob das Kennwort in der Datei mit dem ersten Knoten identisch ist, und ersetzen Sie Folgendes: 

update mysql.user set password=PASSWORD('password_from_debian.cnf') where User='debian-sys-maint';

Wiederholen Sie diesen Vorgang, um die verbleibenden Knoten zu testen.

[[Schritt 8 - Testen der Replikation]] == Schritt 8 - Testen der Replikation

Wir haben die Schritte bis zu diesem Punkt durchlaufen, damit unser Cluster die Replikation von einem beliebigen Knoten auf einen anderen Knoten ausführen kann, der als Aktiv-Aktiv- oder Master-Master-Replikation bezeichnet wird. Testen wir, ob die Replikation wie erwartet funktioniert.

Schreiben Sie an den ersten Knoten:

Wir beginnen mit Datenbankänderungen auf unserem ersten Knoten. Mit den folgenden Befehlen wird eine Datenbank mit dem Namenplayground und eine Tabelle mit dem Namenequipment erstellt. 

mysql -u root -p -e 'CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");'

Wir haben jetzt einen Wert in unserer Tabelle.

Lesen und Schreiben auf dem zweiten Knoten:

Als Nächstes überprüfen wir anhand des zweiten Knotens, ob die Replikation funktioniert: 

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Wenn die Replikation funktioniert, werden die Daten, die wir auf dem ersten Knoten eingegeben haben, hier auf dem zweiten Knoten angezeigt: 

Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+

Von demselben Knoten aus können wir Daten in den Cluster schreiben: 

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");'

Lesen und Schreiben auf dem dritten Knoten:

Vom dritten Knoten können wir alle diese Daten lesen, indem wir erneut Folgendes abfragen: 

mysql -u root -p -e 'SELECT * FROM playground.equipment;'
Output   +----+-------+-------+--------+
   | id | type  | quant | color  |
   +----+-------+-------+--------+
   |  1 | slide |     2 | blue   |
   |  2 | swing |    10 | yellow |
   +----+-------+-------+--------+

Wieder können wir einen weiteren Wert von diesem Knoten hinzufügen: 

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");'

Lesen Sie auf dem ersten Knoten:

Zurück auf dem ersten Knoten können wir überprüfen, ob unsere Daten überall verfügbar sind: 

mysql -u root -p -e 'SELECT * FROM playground.equipment;'
Output   +----+--------+-------+--------+
   | id | type   | quant | color  |
   +----+--------+-------+--------+
   |  1 | slide  |     2 | blue   |
   |  2 | swing  |    10 | yellow |
   |  3 | seesaw |     3 | green  |
   +----+--------+-------+--------+

Wir haben getestet, dass wir auf alle Knoten schreiben können und dass die Replikation ordnungsgemäß ausgeführt wird.

Fazit

Zu diesem Zeitpunkt sollte ein funktionierender Galera-Testcluster mit drei Knoten konfiguriert sein. Wenn Sie vorhaben, einen Galera-Cluster in einer Produktionssituation zu verwenden, wird empfohlen, mit mindestens fünf Knoten zu beginnen.

Vor der Verwendung in der Produktion sollten Sie sich einigeother state snapshot transfer (sst) agentswie "xtrabackup" ansehen, mit denen Sie sehr schnell und ohne große Unterbrechungen Ihrer aktiven Knoten neue Knoten einrichten können. Dies hat keine Auswirkungen auf die tatsächliche Replikation, ist jedoch ein Problem, wenn Knoten initialisiert werden.

Wenn sich Ihre Clustermitglieder nicht in einem privaten Netzwerk befinden, müssen Sie außerdemSSL einrichten, um Ihre Daten beim Wechsel zwischen Servern zu schützen.

Related