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

Bereitstellen von MariaDB Sharding mit Spider unter Verwendung von ClusterControl

MariaDB bietet integrierte Multi-Host-Sharding-Funktionen mit der Spider-Speicher-Engine. Spider unterstützt Partitionierung und XA-Transaktionen und ermöglicht die Behandlung entfernter Tabellen verschiedener MariaDB-Instanzen, als ob sie sich auf derselben Instanz befänden. Die entfernte Tabelle kann eine beliebige Speicher-Engine sein. Die Tabellenverknüpfung wird durch die Herstellung der Verbindung von einem lokalen MariaDB-Server zu einem Remote-MariaDB-Server erreicht, und die Verknüpfung wird für alle Tabellen geteilt, die Teil derselben Transaktion sind.

In diesem Blogbeitrag führen wir Sie durch die Bereitstellung eines Clusters aus zwei MariaDB-Shards mit ClusterControl. Wir werden eine Handvoll MariaDB-Server (für Redundanz und Verfügbarkeit) bereitstellen, um eine partitionierte Tabelle basierend auf einem Bereich eines ausgewählten Shard-Schlüssels zu hosten. Der gewählte Shard-Schlüssel ist im Grunde eine Spalte, die Werte mit einer Unter- und Obergrenze speichert, wie in diesem Fall ganzzahlige Werte zwischen 0 und 1.000.000, was ihn zum besten Kandidatenschlüssel macht, um die Datenverteilung zwischen zwei Shards auszugleichen. Daher werden wir die Bereiche in zwei Partitionen unterteilen:

  • 0 - 499999:Shard 1

  • 500000 - 1000000:Splitter 2

Das folgende Diagramm veranschaulicht unsere High-Level-Architektur dessen, was wir bereitstellen werden:

Einige Erläuterungen zum Diagramm:

  1. mariadb-gw-1:MariaDB-Instanz, die die Spider-Speicher-Engine ausführt, verhält sich wie ein Shard-Router. Wir geben diesem Host einen Namen als MariaDB Gateway 1 und dies wird der primäre (aktive) MariaDB-Server sein, um die Shards zu erreichen. Die Anwendung stellt wie eine Standard-MariaDB-Verbindung eine Verbindung zu diesem Host her. Dieser Knoten stellt über HAProxy eine Verbindung zu den Shards her und überwacht die 127.0.0.1-Ports 3307 (Shard1) und 3308 (Shard2).

  2. mariadb-gw-2:MariaDB-Instanz, die die Spider-Speicher-Engine ausführt, verhält sich wie ein Shard-Router. Wir geben diesem Host einen Namen als MariaDB Gateway 2 und dies wird der sekundäre (passive) MariaDB-Server sein, um die Shards zu erreichen. Es wird das gleiche Setup wie mariadb-gw-1 haben. Die Anwendung stellt nur dann eine Verbindung zu diesem Host her, wenn die primäre MariaDB ausgefallen ist. Dieser Knoten stellt über HAProxy eine Verbindung zu den Shards her und überwacht die 127.0.0.1-Ports 3307 (Shard1) und 3308 (Shard2).

  3. mariadb-shard-1a:MariaDB-Master, der als primärer Datenknoten für die erste Partition dient. MariaDB-Gateway-Server sollten nur an den Master des Shards schreiben.

  4. mariadb-shard-1b:MariaDB-Replikat, das als sekundärer Datenknoten für die erste Partition dient. Es soll die Master-Rolle übernehmen, falls der Master des Shards ausfällt (automatisches Failover wird von ClusterControl verwaltet).

  5. mariadb-shard-2a:MariaDB-Master, der als primärer Datenknoten für die zweite Partition dient. MariaDB-Gateway-Server schreiben nur an den Master des Shards.

  6. mariadb-shard-2b:MariaDB-Replikat, das als sekundärer Datenknoten für die zweite Partition dient. Es soll die Master-Rolle übernehmen, falls der Master des Shards ausfällt (automatisches Failover wird von ClusterControl verwaltet).

  7. ClusterControl:Ein zentralisiertes Bereitstellungs-, Verwaltungs- und Überwachungstool für unsere MariaDB-Shards/Cluster.

Bereitstellen von Datenbank-Clustern mit ClusterControl

ClusterControl ist ein Automatisierungstool zur Verwaltung des Lebenszyklus Ihres Open-Source-Datenbankverwaltungssystems. Wir werden ClusterControl als zentralisiertes Tool für Cluster-Bereitstellungen, Topologieverwaltung und Überwachung für die Zwecke dieses Blogbeitrags verwenden.

1) ClusterControl installieren.

2) Konfigurieren Sie das passwortlose SSH vom ClusterControl-Server zu allen Datenbankknoten. Auf dem ClusterControl-Knoten:

(clustercontrol)$ whoami
root
$ ssh-keygen -t rsa
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]

3) Da wir 4 Gruppen von Clustern bereitstellen werden, ist es eine gute Idee, das CLI-Tool ClusterControl für diese spezielle Aufgabe zu verwenden, um den Bereitstellungsprozess zu beschleunigen und zu vereinfachen. Lassen Sie uns zunächst überprüfen, ob wir eine Verbindung mit den Standard-Anmeldeinformationen herstellen können, indem Sie den folgenden Befehl ausführen (die Standard-Anmeldeinformationen werden automatisch in /etc/s9s.conf konfiguriert):

(clustercontrol)$ s9s cluster --list --long
Total: 0

Wenn wir keine Fehler erhalten und eine ähnliche Ausgabe wie oben sehen, können wir loslegen.

4) Beachten Sie, dass die Schritte 4,5,6 und 7 gleichzeitig ausgeführt werden können, da ClusterControl die parallele Bereitstellung unterstützt. Wir beginnen mit der Bereitstellung des ersten MariaDB-Gateway-Servers mithilfe der ClusterControl-CLI:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.101?master" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB Gateway 1"

5) Stellen Sie den zweiten MariaDB-Gateway-Server bereit:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.102?master" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB Gateway 2"

6) Stellen Sie eine 2-Knoten-MariaDB-Replikation für den ersten Shard bereit:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.111?master;192.168.22.112?slave" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB - Shard 1"

7) Stellen Sie eine 2-Knoten-MariaDB-Replikation für den zweiten Shard bereit:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.121?master;192.168.22.122?slave" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB - Shard 2"

Während die Bereitstellung läuft, können wir die Jobausgabe von CLI überwachen:

(clustercontrol)$ s9s job --list --show-running
ID CID STATE   OWNER GROUP  CREATED  RDY TITLE
25   0 RUNNING admin admins 07:19:28  45% Create MySQL Replication Cluster
26   0 RUNNING admin admins 07:19:38  45% Create MySQL Replication Cluster
27   0 RUNNING admin admins 07:20:06  30% Create MySQL Replication Cluster
28   0 RUNNING admin admins 07:20:14  30% Create MySQL Replication Cluster

Und auch von der ClusterControl-Benutzeroberfläche:

Sobald die Bereitstellung abgeschlossen ist, sollten die Datenbank-Cluster aufgelistet werden wie folgt im ClusterControl-Dashboard:

Unsere Cluster sind jetzt bereitgestellt und führen die neueste MariaDB 10.5 aus. Als Nächstes müssen wir HAProxy konfigurieren, um einen einzelnen Endpunkt für die MariaDB-Shards bereitzustellen.

HAProxy konfigurieren

HAProxy ist als einzelner Endpunkt für die Master-Slave-Replikation des Shards erforderlich. Andernfalls, wenn ein Master ausfällt, muss man die Serverliste von Spider mit der CREATE OR REPLACE SERVER-Anweisung in den Gateway-Servern aktualisieren und dann ALTER TABLE ausführen und einen neuen Verbindungsparameter übergeben. Mit HAProxy können wir es so konfigurieren, dass es auf dem lokalen Host des Gateway-Servers lauscht und verschiedene MariaDB-Shards mit unterschiedlichen Ports überwacht. Wir werden HAProxy auf beiden Gateway-Servern wie folgt konfigurieren:

  • 127.0.0.1:3307 -> Shard1 (Backend-Server sind mariadb-shard-1a und mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (Backend-Server sind mariadb-shard-2a und mariadb-shard- 2b)

Falls der Master des Shards ausfällt, übernimmt ClusterControl den Slave des Shards als neuen Master und HAProxy leitet die Verbindungen entsprechend zum neuen Master um. Wir werden HAProxy auf den Gateway-Servern (mariadb-gw-1 und mariadb-gw-2) mit ClusterControl installieren, da es automatisch die Backend-Server (mysqlchk-Setup, Benutzerberechtigungen, xinetd-Installation) mit einigen Tricks wie unten gezeigt konfiguriert.

Wählen Sie zunächst auf der ClusterControl-Benutzeroberfläche den ersten Shard MariaDB - Shard 1 -> Manage -> Load Balancers -> HAProxy -> HAProxy bereitstellen und geben Sie die Serveradresse als 192.168.22.101 ( mariadb-gw-1), ähnlich dem folgenden Screenshot:

Ähnlich, aber dieser für Shard 2, gehen Sie zu MariaDB - Shard 2 -> Verwalten -> Load Balancer -> HAProxy -> HAProxy bereitstellen und geben Sie die Serveradresse als 192.168.22.102 (mariadb-gw-2) an. Warten Sie, bis die Bereitstellung für beide HAProxy-Knoten abgeschlossen ist.

Jetzt müssen wir den HAProxy-Dienst auf mariadb-gw-1 und mariadb-gw-2 konfigurieren, um alle Shards auf einmal auszugleichen. Bearbeiten Sie mit dem Texteditor (oder der ClusterControl-Benutzeroberfläche -> Verwalten -> Konfigurationen) die letzten beiden "listen"-Anweisungen der /etc/haproxy/haproxy.cfg so, dass sie wie folgt aussehen:

listen  haproxy_3307_shard1
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check connect port 9200
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.22.111 192.168.22.111:3306 check # mariadb-shard-1a-master
        server 192.168.22.112 192.168.22.112:3306 check # mariadb-shard-1b-slave

listen  haproxy_3308_shard2
        bind *:3308
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check connect port 9200
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.22.121 192.168.22.121:3306 check # mariadb-shard-2a-master
        server 192.168.22.122 192.168.22.122:3306 check # mariadb-shard-2b-slave

Starten Sie den HAProxy-Dienst neu, um die Änderungen zu laden (oder verwenden Sie ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

Über die ClusterControl-Benutzeroberfläche können wir überprüfen, dass nur ein Backend-Server pro Shard aktiv ist (angezeigt durch die grünen Linien), wie unten gezeigt:

Zu diesem Zeitpunkt ist die Bereitstellung unseres Datenbankclusters nun abgeschlossen. Wir können mit der Konfiguration des MariaDB-Shardings mit der Spider-Speicher-Engine fortfahren.

MariaDB-Gateway-Server vorbereiten

Führen Sie auf beiden MariaDB-Gateway-Servern (mariadb-gw-1 und mariadb-gw-2) die folgenden Aufgaben aus:

Spider-Plugin installieren:

MariaDB> INSTALL PLUGIN spider SONAME 'ha_spider.so';

Überprüfen Sie, ob die Speicher-Engine unterstützt wird:

MariaDB> SELECT engine,support FROM information_schema.engines WHERE engine = 'spider';
+--------+---------+
| engine | support |
+--------+---------+
| SPIDER | YES     |
+--------+---------+

Optional können wir auch überprüfen, ob das Plugin korrekt aus der information_schema-Datenbank geladen wird:

MariaDB> SELECT PLUGIN_NAME,PLUGIN_VERSION,PLUGIN_STATUS,PLUGIN_TYPE FROM information_schema.plugins WHERE plugin_name LIKE 'SPIDER%';
+--------------------------+----------------+---------------+--------------------+
| PLUGIN_NAME              | PLUGIN_VERSION | PLUGIN_STATUS | PLUGIN_TYPE        |
+--------------------------+----------------+---------------+--------------------+
| SPIDER                   | 3.3            | ACTIVE        | STORAGE ENGINE     |
| SPIDER_ALLOC_MEM         | 1.0            | ACTIVE        | INFORMATION SCHEMA |
| SPIDER_WRAPPER_PROTOCOLS | 1.0            | ACTIVE        | INFORMATION SCHEMA |
+--------------------------+----------------+---------------+--------------------+

Fügen Sie die folgende Zeile unter dem Abschnitt [mysqld] in der MariaDB-Konfigurationsdatei hinzu:

plugin-load-add = ha_spider

Erstellen Sie den ersten "Datenknoten" für den ersten Shard, der über HAProxy 127.0.0.1 auf Port 3307 erreichbar sein soll:

MariaDB> CREATE OR REPLACE SERVER Shard1 
FOREIGN DATA WRAPPER mysql
OPTIONS (
   HOST '127.0.0.1',
   DATABASE 'sbtest',
   USER 'spider',
   PASSWORD 'SpiderP455',
   PORT 3307);

Erstellen Sie den zweiten "Datenknoten" für den zweiten Shard, der über HAProxy 127.0.0.1 auf Port 3308 erreichbar sein soll:

CREATE OR REPLACE SERVER Shard2 
FOREIGN DATA WRAPPER mysql
OPTIONS (
   HOST '127.0.0.1',
   DATABASE 'sbtest',
   USER 'spider',
   PASSWORD 'SpiderP455',
   PORT 3308);

Jetzt können wir eine Spider-Tabelle erstellen, die partitioniert werden muss. In diesem Beispiel erstellen wir eine Tabelle mit dem Namen sbtest1 in der Datenbank sbtest und partitionieren nach dem ganzzahligen Wert in der Spalte „k“:

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE TABLE sbtest.sbtest1 (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`, `k`)
)
  ENGINE=Spider
  COMMENT 'wrapper "mysql", table "sbtest1"'
  PARTITION BY RANGE (k) (
    PARTITION shard1 VALUES LESS THAN (499999) COMMENT = 'srv "Shard1"',
    PARTITION shard2 VALUES LESS THAN MAXVALUE COMMENT = 'srv "Shard2"'
);

Beachten Sie, dass die COMMENT ='srv "ShardX"'-Klauseln der CREATE TABLE-Anweisung kritisch sind, wo wir Verbindungsinformationen über den entfernten Server übergeben. Der Wert muss mit dem Servernamen wie in der CREATE SERVER-Anweisung identisch sein. Wir werden diese Tabelle mit dem Sysbench-Lastgenerator füllen, wie weiter unten gezeigt.

Erstellen Sie den Anwendungsdatenbankbenutzer, um auf die Datenbank zuzugreifen, und erlauben Sie ihm von den Anwendungsservern:

MariaDB> CREATE USER [email protected]'192.168.22.%' IDENTIFIED BY 'passw0rd';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';

In diesem Beispiel verwenden wir, da es sich um ein vertrauenswürdiges internes Netzwerk handelt, einfach einen Platzhalter in der Anweisung, um jede IP-Adresse im selben Bereich, 192.168.22.0/24, zuzulassen.

Wir können jetzt unsere Datenknoten konfigurieren.

MariaDB-Shard-Server vorbereiten

Führen Sie auf beiden MariaDB-Shard-Masterservern (mariadb-shard-1a und mariadb-shard-2a) die folgenden Aufgaben aus:

1) Erstellen Sie die Zieldatenbank:

MariaDB> CREATE SCHEMA sbtest;

2) Erstellen Sie den 'spider'-Benutzer und erlauben Sie Verbindungen von den Gateway-Servern (mariadb-gw-1 und mariadb-gw2). Dieser Benutzer muss alle Berechtigungen für die Sharding-Tabelle und auch für die MySQL-Systemdatenbank haben:

MariaDB> CREATE USER 'spider'@'192.168.22.%' IDENTIFIED BY 'SpiderP455';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';
MariaDB> GRANT ALL ON mysql.* TO [email protected]'192.168.22.%';

In diesem Beispiel verwenden wir, da es sich um ein vertrauenswürdiges internes Netzwerk handelt, einfach einen Platzhalter in der Anweisung, um jede IP-Adresse im selben Bereich, 192.168.22.0/24, zuzulassen.

3) Erstellen Sie die Tabelle, die die Daten von unseren Gateway-Servern über die Spider-Speicher-Engine erhalten wird. Diese „Empfänger“-Tabelle kann sich auf jeder von MariaDB unterstützten Speicher-Engine befinden. In diesem Beispiel verwenden wir die InnoDB-Speicher-Engine:

MariaDB> CREATE TABLE sbtest.sbtest1 (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`, `k`)
) ENGINE = INNODB;

Das ist es. Vergessen Sie nicht, die Schritte auf dem anderen Shard zu wiederholen.

Testen

Um die Verwendung von Sysbench zum Generieren einiger Datenbank-Workloads auf dem Anwendungsserver zu testen, müssen wir vorher Sysbench installieren:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Generieren Sie einige Test-Workloads und senden Sie sie an den ersten Gateway-Server, mariadb-gw-1 (192.168.11.101):

$ sysbench \
/usr/share/sysbench/oltp_insert.lua \
--report-interval=2 \
--threads=4 \
--rate=20 \
--time=9999 \
--db-driver=mysql \
--mysql-host=192.168.11.101 \
--mysql-port=3306 \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=passw0rd \
--tables=1 \
--table-size=1000000 \
run

Sie können den obigen Test auf mariadb-gw-2 (192.168.11.102) wiederholen und die Datenbankverbindungen sollten entsprechend zum richtigen Shard geleitet werden.

Wenn wir uns den ersten Shard (mariadb-shard-1a oder mariadb-shard-1b) ansehen, können wir erkennen, dass diese Partition nur Zeilen enthält, bei denen der Shard-Schlüssel (Spalte k) kleiner als 500000 ist:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 499963 |
+--------+--------+

Auf einem anderen Shard (mariadb-shard-2a oder mariadb-shard-2b) enthält es wie erwartet Daten von 500000 bis 999999:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 500067 | 999948 |
+--------+--------+

Während für den MariaDB-Gateway-Server (mariadb-gw-1 oder mariadb-gw-2) alle Zeilen ähnlich sehen, wenn die Tabelle in dieser MariaDB-Instanz vorhanden ist:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 999948 |
+--------+--------+

Um den Hochverfügbarkeitsaspekt zu testen, wenn ein Shard-Master nicht verfügbar ist, beispielsweise wenn der Master (mariadb-shard-2a) von Shard 2 ausfällt, führt ClusterControl automatisch die Slave-Promotion durch der Sklave (mariadb-shard-2b) ein Meister zu sein. Während dieser Zeit könnten Sie wahrscheinlich diesen Fehler sehen:

ERROR 1429 (HY000) at line 1: Unable to connect to foreign data source: Shard2

Und während der Nichtverfügbarkeit erhalten Sie den folgenden nachfolgenden Fehler:

ERROR 1158 (08S01) at line 1: Got an error reading communication packets

Bei unserer Messung dauerte das Failover etwa 23 Sekunden, nachdem das Failover begonnen hatte, und sobald der neue Master heraufgestuft wurde, sollten Sie in der Lage sein, wie gewohnt vom Gateway-Server in die Tabelle zu schreiben.

Fazit

Das obige Setup ist ein Beweis dafür, wie ClusterControl verwendet werden kann, um ein MariaDB-Sharding-Setup bereitzustellen. Es kann auch die Dienstverfügbarkeit eines MariaDB-Sharding-Setups mit seiner automatischen Knoten- und Cluster-Wiederherstellungsfunktion sowie allen branchenüblichen Verwaltungs- und Überwachungsfunktionen verbessern, um Ihre gesamte Datenbankinfrastruktur zu unterstützen.