MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

MariaDB MaxScale Load Balancing auf Docker:Management:Teil Zwei

Dieser Blogpost ist eine Fortsetzung von MariaDB MaxScale Load Balancing auf Docker:Bereitstellung – Teil 1. In diesem Teil konzentrieren wir uns mehr auf Verwaltungsvorgänge mit erweiterten Anwendungsfällen wie Dienststeuerung, Konfigurationsverwaltung, Abfrageverarbeitung, Sicherheit und Clusterabgleich. Die in diesem Beitrag gezeigten Beispielschritte und Anweisungen basieren auf den Laufumgebungen, die wir im ersten Teil dieser Blogserie eingerichtet haben.

Dienststeuerung

Für MaxScale ist das Starten und Stoppen des Containers die einzige Möglichkeit, den Dienst zu steuern. Vorausgesetzt, der Container wurde erstellt, können wir den Dienst mit dem folgenden Befehl verwalten:

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

Laufen ohne Root-Rechte

Die Docker-Container werden standardmäßig mit Root-Rechten ausgeführt, ebenso wie die Anwendung, die im Container ausgeführt wird. Dies ist aus Sicherheitssicht ein weiteres großes Problem, da Hacker Root-Zugriff auf den Docker-Host erlangen können, indem sie die Anwendung hacken, die im Container ausgeführt wird.

Um Docker als Nicht-Root-Benutzer auszuführen, müssen Sie Ihren Benutzer zur Docker-Gruppe hinzufügen. Erstellen Sie zunächst eine Docker-Gruppe, falls noch keine vorhanden ist:

$ sudo groupadd docker

Fügen Sie dann Ihren Benutzer zur Docker-Gruppe hinzu. In diesem Beispiel ist unser Benutzer "vagrant":

$ sudo usermod -aG docker vagrant

Melden Sie sich ab und wieder an, damit Ihre Gruppenmitgliedschaft neu bewertet wird (oder starten Sie neu, wenn es nicht funktioniert). An diesem Punkt können Sie den MaxScale-Container mit dem standardmäßigen Ausführungsbefehl (kein sudo erforderlich) als Benutzer „vagrant“ ausführen:

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

Der MaxScale-Prozess wird vom Benutzer „maxscale“ ausgeführt und erfordert keine besonderen Berechtigungen bis zur Root-Ebene. Daher ist es immer am besten, den Container im nicht privilegierten Modus auszuführen, wenn Sie sich Sorgen um die Sicherheit machen.

Konfigurationsverwaltung

Für den eigenständigen MaxScale-Container erfordert die Konfigurationsverwaltung eine Änderung der zugeordneten Konfigurationsdatei, gefolgt von einem Neustart des MaxScale-Containers. Wenn Sie jedoch als Docker Swarm Service laufen, muss die neue Konfiguration als neue Version in die Swarm Configs geladen werden, zum Beispiel:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Aktualisieren Sie dann den Dienst, indem Sie die alten Konfigurationen (maxscale_config) entfernen und die neue (maxscale_config_v2) demselben Ziel hinzufügen:

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

Docker Swarm plant dann das Entfernen von Containern und ersetzt Prozeduren, Container für Container, bis die Replikatanforderungen erfüllt sind.

Upgrade und Downgrade

Einer der Vorteile der Ausführung Ihrer Anwendungen in Docker ist das einfache Upgrade- und Downgrade-Verfahren. Jeder laufende Container basiert auf einem Image, und dieses Image kann einfach mit dem Image-Tag gewechselt werden. Die Liste der verfügbaren Images für MaxScale finden Sie im Abschnitt „Tags“ im Docker-Hub. Die folgenden Beispiele zeigen den Prozess zum Downgrade von MaxScale 2.3 auf eine kleinere Version früher, 2.2:

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

Stellen Sie sicher, dass die Konfigurationsoptionen mit der Version kompatibel sind, die Sie ausführen möchten. Beispielsweise würde das obige Downgrade aufgrund der folgenden Fehler beim ersten Ausführen fehlschlagen:

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

Was wir tun müssen, ist, die nicht unterstützten Konfigurationsoptionen wie oben gezeigt in der Konfigurationsdatei zu entfernen, bevor wir das Container-Image herabstufen:

  • master_reconnection
  • delayed_retry
  • transaction_replay
  • causal_reads_timeout
  • causal_reads

Starten Sie den Container schließlich erneut und Sie sollten gut sein. Das Versions-Upgrade für MaxScale funktioniert ähnlich. Ändern Sie einfach das Tag, das Sie verwenden möchten, und los geht's.

MaxScale-Filter

MaxScale verwendet eine Komponente namens Filter, um die Anforderungen zu manipulieren oder zu verarbeiten, während sie es durchlaufen. Es gibt eine Reihe von Filtern, die Sie verwenden können, wie auf dieser Seite aufgelistet, MaxScale 2.3-Filter. Beispielsweise kann eine bestimmte Abfrage in einer Datei protokolliert werden, wenn sie einem Kriterium entspricht, oder Sie können die eingehende Abfrage umschreiben, bevor sie die Backend-Server erreicht.

Um einen Filter zu aktivieren, müssen Sie einen Abschnitt definieren und den Definitionsnamen in die entsprechende Dienstdefinition aufnehmen, wie in den Beispielen weiter unten gezeigt.

Alle Abfragen protokollieren (QLA)

Wie der Name schon sagt, protokolliert der QLA-Filter alle Abfragen, die mit dem Regelsatz pro Clientsitzung übereinstimmen. Alle Abfragen werden nach dem Filebase-Format protokolliert.

Definieren Sie zunächst die Komponente mit type=filter und module=qlafilter:

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

Dann fügen Sie die Filterkomponente zu unseren Diensten hinzu:

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

Es ist auch eine gute Idee, /tmp des Containers dem tatsächlichen Verzeichnis auf dem Docker-Host zuzuordnen, damit wir nicht auf den Container zugreifen müssen, um die generierten Protokolldateien abzurufen. Erstellen Sie zunächst ein Verzeichnis und geben Sie globale Schreibrechte:

$ mkdir qla
$ chmod 777 qla

Da wir das obige Verzeichnis in den Container binden müssen, müssen wir den laufenden Container stoppen und entfernen und ihn mit dem folgenden Befehl erneut ausführen:

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

Sie können dann den Inhalt der protokollierten Abfragen im qla-Verzeichnis abrufen:

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

Umschreiben von Abfragen

Das Umschreiben von Abfragen ist eine Funktion, mit der abhängig von den Abfragen, die auf dem Datenbankserver ausgeführt werden, problematische Abfragen schnell isoliert und korrigiert und die Leistung verbessert werden können.

Das Umschreiben von Abfragen kann über Regexfilter erfolgen. Dieser Filter kann eingehende Anweisungen mithilfe von regulären Ausdrücken abgleichen oder ausschließen und sie durch eine andere Anweisung ersetzen. Jede Regel wird in einem eigenen Abschnitt definiert und fügen Sie den Abschnittsnamen in den entsprechenden Dienst ein, um ihn zu aktivieren.

Der folgende Filter stimmt mit einer Reihe von SHOW-Befehlen überein, die wir den schreibgeschützten Clients nicht aussetzen möchten:

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

Dann können wir den Filter an den Dienst anhängen, den wir anwenden möchten. Beispielsweise müssen alle Nur-Lese-Verbindungen nach den oben genannten gefiltert werden:

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

Beachten Sie, dass mehrere Filter mit einer Syntax definiert werden können, die der Linux-Shell-Pipe "|" ähnelt. Syntax. Starten Sie den Container neu, um die Konfigurationsänderungen zu übernehmen:

$ docker restart maxscale

Wir können dies dann mit der folgenden Abfrage überprüfen:

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

Sie erhalten das erwartete Ergebnis.

Cluster-Wiederherstellung

MaxScale 2.2.2 und höher unterstützt die automatische oder manuelle MariaDB-Replikation oder Cluster-Wiederherstellung für die folgenden Ereignisse:

  • Failover
  • Umschaltung
  • wieder beitreten
  • Replikation zurücksetzen

Failover für das Master-Slave-Cluster kann und sollte häufig so eingestellt werden, dass es automatisch aktiviert wird. Die Umschaltung muss manuell über MaxAdmin, MaxCtrl oder die REST-Schnittstelle aktiviert werden. Wiederbeitreten kann auf automatisch eingestellt oder manuell aktiviert werden. Diese Funktionen sind im "mariadbmon"-Modul implementiert.

Die folgenden automatischen Failover-Ereignisse sind aufgetreten, wenn wir den aktiven Master 192.168.0.91 absichtlich heruntergefahren haben:

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

Nach Abschluss des Failovers sieht unsere Topologie nun so aus:

Für den Umschaltvorgang ist ein menschliches Eingreifen und eine Möglichkeit über die MaxCtrl-Konsole erforderlich. Angenommen, der alte Master ist wieder betriebsbereit und bereit, zum Master befördert zu werden, können wir die Umschaltoperation durchführen, indem wir den folgenden Befehl senden:

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

Wobei die Formatierung ist:

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

Überprüfen Sie dann die neue Topologie, indem Sie die Server auflisten:

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

Wir haben gerade unseren alten Meister wieder an seinen ursprünglichen Platz befördert. Unterhaltsame Tatsache, die automatische Wiederherstellungsfunktion von ClusterControl macht genau dasselbe, wenn sie aktiviert ist.

Abschließende Gedanken

Die Ausführung von MariaDB MaxScale auf Docker bringt zusätzliche Vorteile wie MaxScale-Clustering, einfaches Upgrade und Downgrade sowie erweiterte Proxy-Funktionen für MySQL- und MariaDB-Cluster.