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

Was ist neu in MariaDB MaxScale 2.4

MaxScale 2.4 wurde am 21. Dezember 2019 veröffentlicht und ClusterControl 1.7.6 unterstützt die Überwachung und Verwaltung bis zu dieser Version. Für die Bereitstellung unterstützt ClusterControl jedoch nur bis Version 2.3. Man muss die Instanz manuell aktualisieren, und glücklicherweise sind die Upgrade-Schritte sehr einfach. Laden Sie einfach die neueste Version von der MariaDB MaxScale-Downloadseite herunter und führen Sie den Paketinstallationsbefehl aus.

Die folgenden Befehle zeigen, wie Sie ein Upgrade von einem vorhandenen MaxScale 2.3 auf MaxScale 2.4 auf einer CentOS 7-Box durchführen:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

In diesem Blogbeitrag werden wir einige der bemerkenswerten Verbesserungen und neuen Funktionen dieser Version hervorheben und wie sie in Aktion aussieht. Eine vollständige Liste der Änderungen in MariaDB MaxScale 2.4 finden Sie im Änderungsprotokoll.

Befehlshistorie im interaktiven Modus

Dies ist im Grunde eine kleine Verbesserung mit großer Auswirkung auf die Effizienz der Verwaltung und Überwachung von MaxScale-Aufgaben. Der interaktive Modus für MaxCtrl hat jetzt seine Befehlshistorie. Der Befehlsverlauf ermöglicht es Ihnen, den ausgeführten Befehl einfach zu wiederholen, indem Sie die Aufwärts- oder Abwärtspfeiltaste drücken. Die Strg+R-Funktionalität (den letzten Befehl abrufen, der mit den von Ihnen angegebenen Zeichen übereinstimmt) ist jedoch immer noch nicht vorhanden.

In den vorherigen Versionen muss man den Standard-Shell-Modus verwenden, um sicherzustellen, dass die Befehle von der .bash_history-Datei erfasst werden.

GTID-Überwachung für Galeramon

Dies ist eine gute Erweiterung für diejenigen, die Galera Cluster mit geografischer Redundanz über asynchrone Replikation, auch bekannt als Cluster-zu-Cluster-Replikation, oder MariaDB-Galera-Cluster-Replikation über MariaDB-Replikation ausführen.

In MaxScale 2.3 und älter sieht es so aus, wenn Sie die Master-Slave-Replikation zwischen MariaDB-Clustern aktiviert haben:

Für MaxScale 2.4 sieht es jetzt so aus (achte auf Galera1's Zeile):

Es ist jetzt einfacher, den Replikationsstatus für alle Knoten von MaxScale ohne anzuzeigen die Notwendigkeit, einzelne Knoten wiederholt zu überprüfen.

SmartRouter

Dies ist eine der neuen Hauptfunktionen in MaxScale 2.4, bei der MaxScale jetzt intelligent genug ist, um zu lernen, welcher Backend-MariaDB-Backend-Server der beste ist, um die Abfrage zu verarbeiten. SmartRouter verfolgt die Leistung oder die Ausführungszeit von Anfragen an die Cluster. Messungen werden mit dem Canonical einer Abfrage als Schlüssel gespeichert. Die kanonische Abfrage ist die SQL, bei der alle benutzerdefinierten Konstanten durch Fragezeichen ersetzt werden, zum Beispiel:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ?

Dies ist eine sehr nützliche Funktion, wenn Sie MariaDB auf einer geografischen Replikation mit mehreren Standorten oder einer Mischung aus MariaDB-Speicher-Engines in einer Replikationskette ausführen, beispielsweise einen dedizierten Slave zur Verarbeitung von Transaktions-Workloads (OLTP ) mit der InnoDB-Speicher-Engine und einem weiteren dedizierten Slave zur Verarbeitung von Analyse-Workloads (OLAP) mit der Columnstore-Speicher-Engine.

Angenommen, wir haben zwei Standorte – Sydney und Singapur, wie im folgenden Diagramm dargestellt:

Der primäre Standort befindet sich in Singapur und hat einen MariaDB-Master und einen Slave , während sich ein weiterer schreibgeschützter Slave in Sydney befindet. Die Anwendung verbindet sich mit der MaxScale-Instanz in ihrem jeweiligen Land mit den folgenden Porteinstellungen:

  • Lese-Schreib-Aufteilung:3306
  • Roundrobin:3307
  • Intelligenter Router:3308

Unsere SmarRouter-Dienst- und Listener-Definitionen lauten:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******
[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

Starten Sie MaxScale neu und senden Sie eine schreibgeschützte Abfrage an beide MaxScale-Knoten in Singapur und Sydney. Wenn die Abfrage vom Round-Robin-Router (Port 3307) verarbeitet wird, sehen wir, dass die Abfrage basierend auf dem Round-Robin-Algorithmus weitergeleitet wird:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Aus dem Obigen können wir erkennen, dass Sydneys MaxScale die obige Anfrage an unseren Singapurer Slave weitergeleitet hat, was per se nicht die beste Routing-Option ist.

Wenn SmartRouter auf Port 3308 lauscht, würden wir sehen, dass die Abfrage an den nächsten Slave in Sydney weitergeleitet wird:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

Und wenn die gleiche Abfrage an unserem Standort in Singapur ausgeführt wird, wird sie an den MariaDB-Slave in Singapur weitergeleitet:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Es gibt jedoch einen Haken. Wenn SmartRouter eine Leseabfrage sieht, deren Canonical noch nie zuvor gesehen wurde, sendet er die Abfrage an alle Cluster. Die erste Antwort von einem Cluster kennzeichnet diesen Cluster als den besten für diese kanonische. Wenn die erste Antwort empfangen wird, werden auch die anderen Abfragen abgebrochen. Die Antwort wird an den Client gesendet, sobald alle Cluster auf die Abfrage oder den Abbruch geantwortet haben.

Das heißt, um die kanonische Abfrage (normalisierte Abfrage) zu verfolgen und ihre Leistung zu messen, werden Sie wahrscheinlich sehen, dass die allererste Abfrage bei ihrer ersten Ausführung fehlschlägt, zum Beispiel:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

Aus dem allgemeinen Protokoll in MariaDB Sydney können wir erkennen, dass die erste Abfrage (ID 74) erfolgreich ausgeführt wurde (Verbinden, Abfragen und Beenden), trotz des Fehlers "Lost Connection" von MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Während die identische Folgeanfrage korrekt verarbeitet und mit der richtigen Antwort zurückgegeben wurde:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Schaut man sich noch einmal das allgemeine Protokoll in MariaDB Sydney (ID 75) an, passierten die gleichen Verarbeitungsereignisse wie bei der ersten Abfrage:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

Aus dieser Beobachtung können wir schließen, dass MaxScale gelegentlich die erste Abfrage scheitern lassen muss, um die Leistung zu messen und für die nachfolgenden identischen Abfragen intelligenter zu werden. Ihre Anwendung muss in der Lage sein, diesen „ersten Fehler“ ordnungsgemäß zu verarbeiten, bevor sie zum Client zurückkehrt oder die Transaktion noch einmal versucht.

UNIX-Socket für Server

Es gibt mehrere Möglichkeiten, sich mit einem laufenden MySQL- oder MariaDB-Server zu verbinden. Sie können das Standardnetzwerk TCP/IP mit Host-IP-Adresse und Port (Remote-Verbindung), Named Pipes/Shared Memory unter Windows oder Unix-Socket-Dateien auf Unix-basierten Systemen verwenden. Die UNIX-Socket-Datei ist eine spezielle Art von Datei, die die Kommunikation zwischen verschiedenen Prozessen erleichtert, in diesem Fall dem MySQL-Client und dem Server. Die Socket-Datei ist eine dateibasierte Kommunikation, und Sie können nicht von einem anderen Computer aus auf den Socket zugreifen. Es bietet eine schnellere Verbindung als TCP/IP (kein Netzwerk-Overhead) und einen sichereren Verbindungsansatz, da es nur verwendet werden kann, wenn eine Verbindung zu einem Dienst oder Prozess auf demselben Computer hergestellt wird.

Angenommen, der MaxScale-Server ist auch auf dem MariaDB-Server selbst installiert, können wir stattdessen die Socket-UNIX-Socket-Datei verwenden. Entfernen oder kommentieren Sie im Abschnitt Server die Zeile „address“ und fügen Sie den Socket-Parameter mit dem Speicherort der Socket-Datei hinzu:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Bevor wir die obigen Änderungen anwenden, müssen wir einen MaxScale axscale-Benutzer von localhost erstellen. Auf dem Masterserver:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

Nach einem Neustart zeigt MaxScale den UNIX-Socket-Pfad anstelle der tatsächlichen Adresse, und die Serverliste wird wie folgt angezeigt:

Wie Sie sehen können, werden die Status- und GTID-Informationen korrekt über eine Socket-Verbindung abgerufen. Beachten Sie, dass dieser DB_2 immer noch Port 3306 für die Remote-Verbindungen abhört. Es zeigt nur, dass MaxScale einen Socket verwendet, um sich mit diesem Server zur Überwachung zu verbinden.

Die Verwendung von Socket ist immer besser, da es nur lokale Verbindungen zulässt und sicherer ist. Sie könnten Ihren MariaDB-Server auch vom Netzwerk aus schließen (z. B. --skip-networking) und MaxScale die "externen" Verbindungen verwalten lassen und sie über die UNIX-Socket-Datei an den MariaDB-Server weiterleiten.

Serverentleerung

In MaxScale 2.4 können die Backend-Server geleert werden, was bedeutet, dass bestehende Verbindungen weiter verwendet werden können, aber keine neuen Verbindungen zum Server erstellt werden. Mit der Drain-Funktion können wir eine ordnungsgemäße Wartungsaktivität durchführen, ohne die Benutzererfahrung von der Anwendungsseite aus zu beeinträchtigen. Beachten Sie, dass das Leeren eines Servers länger dauern kann, abhängig von den laufenden Abfragen, die ordnungsgemäß geschlossen werden müssen.

Um einen Server zu leeren, verwenden Sie den folgenden Befehl:

Die Nachwirkung könnte einer der folgenden Zustände sein:

  • Draining - Der Server wird geleert.
  • Drained – Der Server wurde geleert. Der Server wurde geleert und jetzt ist die Anzahl der Verbindungen zum Server auf 0 gesunken.
  • Wartung - Der Server wird gewartet.

Nachdem ein Server geleert wurde, ist der Status des MariaDB-Servers aus Sicht von MaxScale "Maintenance":

Wenn sich ein Server im Wartungsmodus befindet, werden keine Verbindungen zu ihm hergestellt und bestehende Verbindungen werden geschlossen.

Fazit

MaxScale 2.4 bringt viele Verbesserungen und Änderungen gegenüber der vorherigen Version und ist der beste Datenbank-Proxy für MariaDB-Server und alle seine Komponenten.