Ausführen eines MariaDB Galera-Clusters ohne Orchestrierungstools

Wie wir im ersten Teil dieses Blogs gesehen haben, funktioniert ein stark konsistenter Datenbankcluster wie Galera nicht gut mit Container-Orchestrierungstools wie Kubernetes oder Swarm. Wir haben Ihnen gezeigt, wie Sie Galera bereitstellen und das Prozessmanagement für Docker konfigurieren, sodass Sie die volle Kontrolle über das Verhalten behalten. Dieser Blogbeitrag ist die Fortsetzung dessen, wir werden uns mit dem Betrieb und der Wartung des Clusters befassen.

Um einige der wichtigsten Punkte aus Teil 1 dieses Blogs zusammenzufassen, haben wir einen Galera-Cluster mit drei Knoten bereitgestellt, mit ProxySQL und Keepalived auf drei verschiedenen Docker-Hosts, auf denen alle MariaDB-Instanzen als Docker-Container ausgeführt werden. Das folgende Diagramm veranschaulicht die endgültige Bereitstellung:

Ordentliches Herunterfahren

Um ein ordnungsgemäßes Herunterfahren von MySQL durchzuführen, senden Sie am besten SIGTERM (Signal 15) an den Container:

$ docker kill -s 15 {db_container_name}

Wenn Sie den Cluster herunterfahren möchten, wiederholen Sie den obigen Befehl für alle Datenbankcontainer, Knoten für Knoten. Das Obige ähnelt dem Ausführen von „systemctl stop mysql“ im systemd-Dienst für MariaDB. Die Verwendung des Befehls „docker stop“ ist für den Datenbankdienst ziemlich riskant, da er auf eine Zeitüberschreitung von 10 Sekunden wartet und Docker SIGKILL erzwingt, wenn diese Dauer überschritten wird (es sei denn, Sie verwenden ein geeignetes --timeout). Wert).

Der letzte Knoten, der ordnungsgemäß heruntergefahren wird, hat die seqno ungleich -1 und safe_to_bootstrap Flag in /{datadir volume}/grastate.dat des Docker-Hosts auf 1 gesetzt ist, zum Beispiel auf host2:

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

Den fortschrittlichsten Knoten erkennen

Wenn der Cluster nicht ordnungsgemäß heruntergefahren wurde oder der Knoten, den Sie zu booten versuchten, nicht der letzte Knoten war, der den Cluster verlassen hat, könnten Sie wahrscheinlich keinen der Galera-Knoten booten und es könnte der folgende Fehler auftreten :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Galera berücksichtigt den Knoten mit safe_to_bootstrap Flag als erster Referenzknoten auf 1 gesetzt. Dies ist der sicherste Weg, um Datenverluste zu vermeiden und sicherzustellen, dass immer der richtige Knoten gebootstrapped wird.

Wenn Sie den Fehler erhalten haben, müssen wir zuerst den am weitesten fortgeschrittenen Knoten herausfinden, bevor wir den Knoten als ersten für das Bootstrapping auswählen. Erstellen Sie einen transienten Container (mit --rm Flag), ordnen Sie es mit zwei MySQL-Befehlsflags, --wsrep_recover, demselben Datenverzeichnis und Konfigurationsverzeichnis des eigentlichen Datenbankcontainers zu und --wsrep_cluster_address . Wenn wir zum Beispiel die letzte festgeschriebene Nummer von mariadb1 wissen wollen, müssen wir Folgendes ausführen:

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

Die letzte Zeile ist das, wonach wir suchen. MariaDB gibt die Cluster-UUID und die Sequenznummer der zuletzt festgeschriebenen Transaktion aus. Der Knoten mit der höchsten Nummer gilt als der am weitesten fortgeschrittene Knoten. Da wir --rm angegeben haben , wird der Container automatisch entfernt, sobald er beendet wird. Wiederholen Sie den obigen Schritt auf jedem Docker-Host, indem Sie --volume ersetzen Pfad zu den jeweiligen Datenbank-Container-Volumes.

Nachdem Sie den von allen Datenbankcontainern gemeldeten Wert verglichen und entschieden haben, welcher Container der aktuellste Knoten ist, ändern Sie safe_to_bootstrap manuell in /{datadir volume}/grastate.dat auf 1 setzen. Nehmen wir an, alle Knoten melden genau dieselbe Sequenznummer. Wir können einfach mariadb3 zum Bootstrapping auswählen, indem wir safe_to_bootstrap ändern Wert auf 1:

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

Speichern Sie die Datei und beginnen Sie mit dem Bootstrapping des Clusters von diesem Knoten, wie im nächsten Kapitel beschrieben.

Bootstrapping des Clusters

Das Bootstrapping des Clusters ähnelt dem ersten Docker-Run-Befehl, den wir beim ersten Start des Clusters verwendet haben. Wenn mariadb1 der gewählte Bootstrap-Knoten ist, können wir den erstellten Bootstrap-Container einfach erneut ausführen:

$ docker start mariadb0 # on host1

Andernfalls, wenn der Bootstrap-Container auf dem ausgewählten Knoten nicht vorhanden ist, sagen wir auf host2, führen Sie den Bootstrap-Container-Befehl aus und ordnen Sie die vorhandenen Volumes von mariadb2 zu. Wir verwenden mariadb0 als Containernamen auf host2, um anzuzeigen, dass es sich um einen Bootstrap-Container handelt:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Möglicherweise stellen Sie fest, dass dieser Befehl im Vergleich zum vorherigen Bootstrap-Befehl, der in diesem Handbuch beschrieben wurde, etwas kürzer ist. Da wir den Proxysql-Benutzer bereits in unserem ersten Bootstrap-Befehl erstellt haben, können wir diese beiden Umgebungsvariablen überspringen:

--env MYSQL_USER=proxysql
--env MYSQL_PASSWORD=proxysqlpassword

Starten Sie dann die verbleibenden MariaDB-Container, entfernen Sie den Bootstrap-Container und starten Sie den vorhandenen MariaDB-Container auf dem Bootstrap-Host. Grundsätzlich wäre die Reihenfolge der Befehle:

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

An diesem Punkt wird der Cluster gestartet und läuft mit voller Kapazität.

Ressourcenkontrolle

Arbeitsspeicher ist eine sehr wichtige Ressource in MySQL. Hier werden die Puffer und Caches gespeichert, und es ist für MySQL von entscheidender Bedeutung, die Auswirkungen eines zu häufigen Zugriffs auf die Festplatte zu reduzieren. Andererseits ist das Austauschen schlecht für die Leistung von MySQL. Standardmäßig gibt es keine Ressourcenbeschränkungen für die ausgeführten Container. Container verwenden so viel von einer bestimmten Ressource, wie es der Kernel des Hosts zulässt. Eine weitere wichtige Sache ist die Begrenzung der Dateideskriptoren. Sie können das Limit für den offenen Dateideskriptor oder "nofile" auf einen höheren Wert erhöhen, um die Anzahl der Dateien zu berücksichtigen, die der MySQL-Server gleichzeitig öffnen kann. Das Festlegen eines hohen Werts schadet nicht.

Um die Speicherzuweisung zu begrenzen und das Dateideskriptorlimit für unseren Datenbankcontainer zu erhöhen, würde man --memory anhängen , --memory-swap und --ulimit Parameter in den "docker run"-Befehl:

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Beachten Sie, dass if --memory-swap auf den gleichen Wert wie --memory gesetzt , und --memory auf eine positive Ganzzahl gesetzt ist, hat der Container keinen Zugriff auf Swap. Wenn --memory-swap nicht gesetzt ist, wird Container Swap standardmäßig auf --memory gesetzt mit 2 multiplizieren. Wenn --memory und --memory-swap auf denselben Wert gesetzt sind, verhindert dies, dass Container einen Swap verwenden. Das liegt daran, dass --memory-swap ist die Menge an kombiniertem Speicher und Swap, die verwendet werden kann, während --memory ist nur die Menge an physischem Speicher, die verwendet werden kann.

Einige der Container-Ressourcen wie Speicher und CPU können dynamisch über den Befehl „docker update“ gesteuert werden, wie im folgenden Beispiel gezeigt, um den Speicher des Containers mariadb1 on-the-fly auf 32 GB zu aktualisieren:

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

Vergessen Sie nicht, die my.cnf entsprechend den neuen Spezifikationen anzupassen. Das Konfigurationsmanagement wird im nächsten Abschnitt erläutert.

Konfigurationsverwaltung

Die meisten MySQL/MariaDB-Konfigurationsparameter können während der Laufzeit geändert werden, was bedeutet, dass Sie nicht neu starten müssen, um die Änderungen zu übernehmen. Weitere Informationen finden Sie auf der MariaDB-Dokumentationsseite. Der mit „Dynamisch:Ja“ aufgeführte Parameter bedeutet, dass die Variable bei Änderung sofort geladen wird, ohne dass der MariaDB-Server neu gestartet werden muss. Legen Sie andernfalls die Parameter in der benutzerdefinierten Konfigurationsdatei im Docker-Host fest. Nehmen Sie beispielsweise auf mariadb3 die Änderungen an der folgenden Datei vor:

$ vim /containers/mariadb3/conf.d/my.cnf

Starten Sie dann den Datenbankcontainer neu, um die Änderung zu übernehmen:

$ docker restart mariadb3

Überprüfen Sie, ob der Container den Prozess startet, indem Sie sich die Docker-Protokolle ansehen. Führen Sie diesen Vorgang auf jeweils einem Knoten aus, wenn Sie clusterweite Änderungen vornehmen möchten.

Sicherung

Das Erstellen eines logischen Backups ist ziemlich einfach, da das MariaDB-Image auch mit der mysqldump-Binärdatei geliefert wird. Sie verwenden einfach den Befehl „docker exec“, um mysqldump auszuführen und die Ausgabe an eine Datei relativ zum Hostpfad zu senden. Der folgende Befehl führt eine mysqldump-Sicherung auf mariadb2 durch und speichert sie unter /backups/mariadb2 innerhalb von host2:

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

Binäre Sicherungen wie Percona Xtrabackup oder MariaDB Backup erfordern, dass der Prozess direkt auf das MariaDB-Datenverzeichnis zugreift. Sie müssen dieses Tool entweder innerhalb des Containers oder über den Maschinenhost installieren oder ein dediziertes Image für diesen Zweck wie das Image "perconalab/percona-xtrabackup" verwenden, um das Backup zu erstellen und es in /tmp/backup auf dem Docker-Host zu speichern:

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

Sie können den Container auch mit innodb_fast_shutdown stoppen auf 0 setzen und das datadir-Volume an einen anderen Ort auf dem physischen Host kopieren:

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

Wiederherstellen

Die Wiederherstellung ist für mysqldump ziemlich einfach. Sie können die Standardeingabe einfach vom physischen Host in den Container umleiten:

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

Sie können auch die standardmäßige mysql-Client-Befehlszeile mit dem richtigen Hostnamen und Portwert verwenden, anstatt diesen „docker exec“-Befehl zu verwenden:

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

Für Percona Xtrabackup und MariaDB Backup müssen wir das Backup vorher vorbereiten. Dadurch wird die Sicherung bis zu dem Zeitpunkt aktualisiert, an dem die Sicherung abgeschlossen war. Nehmen wir an, unsere Xtrabackup-Dateien befinden sich unter /tmp/backup des Docker-Hosts, um sie vorzubereiten, einfach:

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

Das vorbereitete Backup unter /tmp/backup des Docker-Hosts kann dann als MariaDB-Datenverzeichnis für einen neuen Container oder Cluster verwendet werden. Angenommen, wir möchten nur die Wiederherstellung auf einem eigenständigen MariaDB-Container überprüfen, würden wir Folgendes ausführen:

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

Wenn Sie eine Sicherung mit Stop-and-Copy-Ansatz durchgeführt haben, können Sie einfach das Datadir duplizieren und das duplizierte Verzeichnis als Volume-Maps zu MariaDB Datadir verwenden, um es auf einem anderen Container auszuführen. Angenommen, das Backup wurde unter /backups/mariadb2/datadir_copied kopiert, wir können einen neuen Container ausführen, indem wir Folgendes ausführen:

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

Das MYSQL_ROOT_PASSWORD muss mit dem tatsächlichen Root-Passwort für diese bestimmte Sicherung übereinstimmen.

Multiplenines MySQL on Docker:How to Containerize Your DatabaseEntdecken Sie alles, was Sie verstehen müssen, wenn Sie erwägen, einen MySQL-Dienst zusätzlich zur Docker-Containervirtualisierung auszuführen. Laden Sie das Whitepaper herunter

Upgrade der Datenbankversion

Es gibt zwei Arten von Upgrades:direktes Upgrade oder logisches Upgrade.

Ein In-Place-Upgrade umfasst das Herunterfahren des MariaDB-Servers, das Ersetzen der alten Binärdateien durch die neuen Binärdateien und das anschließende Starten des Servers im alten Datenverzeichnis. Nach dem Start müssen Sie mysql_upgrade ausführen Skript zum Überprüfen und Aktualisieren aller Systemtabellen und auch zum Überprüfen der Benutzertabellen.

Das logische Upgrade umfasst das Exportieren von SQL aus der aktuellen Version mithilfe eines logischen Sicherungsdienstprogramms wie mysqldump, das Ausführen des neuen Containers mit den Binärdateien der aktualisierten Version und das anschließende Anwenden des SQL auf die neue MySQL/MariaDB-Version. Es ähnelt dem im vorherigen Abschnitt beschriebenen Sicherungs- und Wiederherstellungsansatz.

Trotzdem ist es ein guter Ansatz, Ihre Datenbank immer zu sichern, bevor Sie destruktive Operationen durchführen. Die folgenden Schritte sind erforderlich, wenn Sie ein Upgrade vom aktuellen Image MariaDB 10.1.33 auf eine andere Hauptversion durchführen, MariaDB 10.2.15 auf mariadb3 befindet sich auf host3:

Sichern Sie die Datenbank. Es spielt keine Rolle, ob es sich um ein physisches oder logisches Backup handelt, aber letzteres mit mysqldump wird empfohlen.
Laden Sie das neueste Image herunter, auf das wir aktualisieren möchten:
```
$ docker pull mariadb:10.2.15
```

Setzen Sie innodb_fast_shutdown für unseren Datenbankcontainer auf 0:

$ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

Ordnungsgemäßes Herunterfahren des Datenbankcontainers:
```
$ docker kill --signal=TERM mariadb3
```

Erstellen Sie einen neuen Container mit dem neuen Image für unseren Datenbankcontainer. Lassen Sie den Rest der Parameter unverändert, außer dass Sie den neuen Containernamen verwenden (sonst würde es zu Konflikten kommen):

$ docker run -d \
        --name mariadb3-new \
        --hostname mariadb3.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb3/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb3.weave.local

Führen Sie das mysql_upgrade-Skript aus:

$ docker exec -it mariadb3-new mysql_upgrade -uroot -p

Wenn keine Fehler aufgetreten sind, entfernen Sie den alten Container mariadb3 (der neue ist mariadb3-new):
```
$ docker rm -f mariadb3
```
Andernfalls, wenn der Upgrade-Prozess zwischendurch fehlschlägt, können wir auf den vorherigen Container zurückgreifen:
```
$ docker stop mariadb3-new
$ docker start mariadb3
```

Das Upgrade der Hauptversion kann ähnlich wie das Upgrade der Nebenversion durchgeführt werden, außer dass Sie bedenken müssen, dass MySQL/MariaDB nur das Hauptupgrade von der vorherigen Version unterstützt. Wenn Sie MariaDB 10.0 verwenden und auf 10.2 aktualisieren möchten, müssen Sie zuerst auf MariaDB 10.1 aktualisieren, gefolgt von einem weiteren Upgrade-Schritt auf MariaDB 10.2.

Beachten Sie die zwischen den Hauptversionen eingeführten und veralteten Konfigurationsänderungen.

Failover

In Galera sind alle Knoten Master und haben die gleiche Rolle. Mit ProxySQL im Bild wird für Verbindungen, die dieses Gateway passieren, automatisch ein Failover durchgeführt, solange eine primäre Komponente für Galera Cluster läuft (d. h. eine Mehrheit der Knoten aktiv ist). Die Anwendung wird keinen Unterschied feststellen, wenn ein Datenbankknoten ausfällt, da ProxySQL die Verbindungen einfach zu den anderen verfügbaren Knoten umleitet.

Wenn sich die Anwendung unter Umgehung von ProxySQL direkt mit MariaDB verbindet, muss auf der Anwendungsseite ein Failover durchgeführt werden, indem auf den nächsten verfügbaren Knoten verwiesen wird, vorausgesetzt, der Datenbankknoten erfüllt die folgenden Bedingungen:

Status wsrep_local_state_comment is Synced (Der Zustand „Desynced/Donor“ ist auch möglich, nur wenn wsrep_sst_method ist xtrabackup, xtrabackup-v2 oder mariabackup).
Status wsrep_cluster_status ist primär.

In Galera bedeutet ein verfügbarer Knoten nicht, dass er fehlerfrei ist, bis der obige Status verifiziert ist.

Scale-out

Zum Aufskalieren können wir einen neuen Container im selben Netzwerk erstellen und dieselbe benutzerdefinierte Konfigurationsdatei für den vorhandenen Container auf diesem bestimmten Host verwenden. Angenommen, wir möchten den vierten MariaDB-Container auf host3 hinzufügen, können wir dieselbe Konfigurationsdatei verwenden, die für mariadb3 gemountet ist, wie im folgenden Diagramm dargestellt:

Führen Sie zum Aufskalieren den folgenden Befehl auf host3 aus:

$ docker run -d \
        --name mariadb4 \
        --hostname mariadb4.weave.local \
        --net weave \
        --publish "3306:3307" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb4/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local,mariadb4.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb4.weave.local

Sobald der Container erstellt ist, tritt er dem Cluster bei und führt SST durch. Es kann über Port 3307 extern oder außerhalb des Weave-Netzwerks oder über Port 3306 innerhalb des Hosts oder innerhalb des Weave-Netzwerks zugegriffen werden. Es ist nicht mehr erforderlich, mariadb0.weave.local in die Clusteradresse aufzunehmen. Sobald der Cluster skaliert ist, müssen wir den neuen MariaDB-Container über die Verwaltungskonsole zum ProxySQL-Load-Balancing-Set hinzufügen:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Wiederholen Sie die obigen Befehle auf der zweiten ProxySQL-Instanz.

Schließlich für den letzten Schritt (Sie können diesen Teil überspringen, wenn Sie bereits die Anweisung „SAVE .. TO DISK“ in ProxySQL ausgeführt haben), fügen Sie die folgende Zeile in „proxysql.cnf“ hinzu, um sie über den Neustart des Containers auf Host1 und Host2 hinweg persistent zu machen:

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

Und hängen Sie mariadb4-bezogene Zeilen unter der mysql_server-Direktive an:

mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

Speichern Sie die Datei und wir sollten beim nächsten Neustart des Containers gut sein.

Verkleinerung

Zum Herunterskalieren wird der Container einfach ordnungsgemäß heruntergefahren. Der beste Befehl wäre:

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

Denken Sie daran, wenn der Datenbankknoten den Cluster unsauber verlassen hat, war dies nicht Teil der Herunterskalierung und würde die Quorum-Berechnung beeinflussen.

Um den Container aus ProxySQL zu entfernen, führen Sie die folgenden Befehle für beide ProxySQL-Container aus. Zum Beispiel auf proxysql1:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Sie können dann entweder den entsprechenden Eintrag in der proxysql.cnf entfernen oder es einfach so belassen. Aus Sicht von ProxySQL wird es sowieso als OFFLINE erkannt.

Zusammenfassung

Bei Docker wird es etwas anders als beim herkömmlichen Umgang mit MySQL- oder MariaDB-Servern. Der Umgang mit zustandsbehafteten Diensten wie Galera Cluster ist nicht so einfach wie zustandslose Anwendungen und erfordert angemessene Tests und Planung.

In unserem nächsten Blog zu diesem Thema werden wir die Vor- und Nachteile der Ausführung von Galera Cluster auf Docker ohne Orchestrierungstools bewerten.

Ausführen eines MariaDB Galera-Clusters ohne Orchestrierungstools – DB Container Management:Part Two