MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Déploiement de MariaDB Sharding avec Spider à l'aide de ClusterControl

MariaDB offre des capacités de partitionnement multi-hôtes intégrées avec le moteur de stockage Spider. Spider prend en charge le partitionnement et les transactions XA et permet de gérer les tables distantes de différentes instances MariaDB comme si elles se trouvaient sur la même instance. La table distante peut appartenir à n'importe quel moteur de stockage. La liaison de table est réalisée par l'établissement de la connexion d'un serveur MariaDB local à un serveur MariaDB distant, et le lien est partagé pour toutes les tables qui font partie de la même transaction.

Dans cet article de blog, nous allons vous expliquer le déploiement d'un cluster de deux partitions MariaDB à l'aide de ClusterControl. Nous allons déployer une poignée de serveurs MariaDB (pour la redondance et la disponibilité) pour héberger une table partitionnée basée sur une plage d'une clé de partition sélectionnée. La clé de partition choisie est essentiellement une colonne qui stocke des valeurs avec une limite inférieure et supérieure, comme dans ce cas, des valeurs entières comprises entre 0 et 1 000 000, ce qui en fait la meilleure clé candidate pour équilibrer la distribution des données entre deux partitions. Par conséquent, nous diviserons les plages en deux partitions :

  • 0 - 499999 :fragment 1

  • 500000 - 1000000 :fragment 2

Le schéma suivant illustre notre architecture de haut niveau de ce que nous allons déployer :

Quelques explications du schéma :

  1. mariadb-gw-1 :instance MariaDB qui exécute le moteur de stockage Spider, agit comme un routeur de partition. Nous donnons un nom à cet hôte en tant que MariaDB Gateway 1 et ce sera le serveur MariaDB principal (actif) pour atteindre les fragments. L'application se connectera à cet hôte comme une connexion MariaDB standard. Ce nœud se connecte aux fragments via HAProxy en écoutant sur les ports 127.0.0.1 3307 (shard1) et 3308 (shard2).

  2. mariadb-gw-2 :instance MariaDB qui exécute le moteur de stockage Spider, agit comme un routeur de partition. Nous donnons un nom à cet hôte en tant que MariaDB Gateway 2 et ce sera le serveur MariaDB secondaire (passif) pour atteindre les fragments. Il aura la même configuration que mariadb-gw-1. L'application se connectera à cet hôte uniquement si la base de données principale MariaDB est en panne. Ce nœud se connecte aux fragments via HAProxy en écoutant sur les ports 127.0.0.1 3307 (shard1) et 3308 (shard2).

  3. mariadb-shard-1a :maître MariaDB qui sert de nœud de données principal pour la première partition. Les serveurs de passerelle MariaDB ne doivent écrire que sur le maître du fragment.

  4. mariadb-shard-1b :réplique MariaDB qui sert de nœud de données secondaire pour la première partition. Il assumera le rôle de maître en cas de panne du maître du shard (le basculement automatique est géré par ClusterControl).

  5. mariadb-shard-2a :maître MariaDB qui sert de nœud de données principal pour la deuxième partition. Les serveurs de passerelle MariaDB écrivent uniquement sur le maître du fragment.

  6. mariadb-shard-2b :réplique MariaDB qui sert de nœud de données secondaire pour la deuxième partition. Il assumera le rôle de maître en cas de panne du maître du shard (le basculement automatique est géré par ClusterControl).

  7. ClusterControl :un outil centralisé de déploiement, de gestion et de surveillance pour nos partitions/clusters MariaDB.

Déployer des clusters de bases de données à l'aide de ClusterControl

ClusterControl est un outil d'automatisation pour gérer le cycle de vie de votre système de gestion de base de données open source. Nous allons utiliser ClusterControl comme outil centralisé pour les déploiements de clusters, la gestion de la topologie et la surveillance dans le cadre de cet article de blog.

1) Installez ClusterControl.

2) Configurez le SSH sans mot de passe du serveur ClusterControl à tous les nœuds de la base de données. Sur le nœud ClusterControl :

(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) Puisque nous allons déployer 4 ensembles de clusters, c'est une bonne idée d'utiliser l'outil CLI ClusterControl pour cette tâche particulière afin d'accélérer et de simplifier le processus de déploiement. Commençons par vérifier si nous pouvons nous connecter avec les informations d'identification par défaut en exécutant la commande suivante (les informations d'identification par défaut sont configurées automatiquement dans /etc/s9s.conf) :

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

Si nous n'obtenons aucune erreur et voyons une sortie similaire à celle ci-dessus, nous sommes prêts à partir.

4) Notez que les étapes 4, 5, 6 et 7 peuvent être exécutées en même temps car ClusterControl prend en charge le déploiement parallèle. Nous allons commencer par déployer le premier serveur MariaDB Gateway à l'aide de la CLI ClusterControl :

(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) Déployez le deuxième serveur MariaDB Gateway :

(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) Déployez une réplication MariaDB à 2 nœuds pour le premier fragment :

(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) Déployez une réplication MariaDB à 2 nœuds pour le deuxième fragment :

(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"

Pendant que le déploiement est en cours, nous pouvons surveiller la sortie de la tâche à partir de la CLI :

(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

Et également depuis l'interface utilisateur de ClusterControl :

Une fois le déploiement terminé, vous devriez voir quelque chose que les clusters de bases de données sont répertoriés comme ceci dans le tableau de bord ClusterControl :

Nos clusters sont maintenant déployés et exécutent la dernière version de MariaDB 10.5. Ensuite, nous devons configurer HAProxy pour fournir un point de terminaison unique aux fragments MariaDB.

Configurer HAProxy

HAProxy est nécessaire en tant que point de terminaison unique pour la réplication maître-esclave de la partition. Sinon, si un maître tombe en panne, il faut mettre à jour la liste des serveurs de Spider à l'aide de l'instruction CREATE OR REPLACE SERVER dans les serveurs de passerelle, effectuer ALTER TABLE et transmettre un nouveau paramètre de connexion. Avec HAProxy, nous pouvons le configurer pour écouter sur l'hôte local du serveur de passerelle et surveiller différents fragments MariaDB avec différents ports. Nous allons configurer HAProxy sur les deux serveurs de passerelle comme suit :

  • 127.0.0.1:3307 -> Shard1 (les serveurs principaux sont mariadb-shard-1a et mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (les serveurs principaux sont mariadb-shard-2a et mariadb-shard- 2b)

En cas de panne du maître du fragment, ClusterControl basculera l'esclave du fragment en tant que nouveau maître et HAProxy redirigera les connexions vers le nouveau maître en conséquence. Nous allons installer HAProxy sur les serveurs de passerelle (mariadb-gw-1 et mariadb-gw-2) à l'aide de ClusterControl car il configurera automatiquement les serveurs principaux (configuration mysqlchk, subventions utilisateur, installation xinetd) avec quelques astuces comme indiqué ci-dessous.

Tout d'abord, sur l'interface utilisateur de ClusterControl, choisissez le premier fragment, MariaDB - Shard 1 -> Manage -> Load Balancers -> HAProxy -> Deploy HAProxy et spécifiez l'adresse du serveur comme 192.168.22.101 ( mariadb-gw-1), similaire à la capture d'écran suivante :

De même, mais celui-ci pour le shard 2, allez sur MariaDB - Shard 2 -> Gérer -> Équilibreurs de charge -> HAProxy -> Déployer HAProxy et spécifiez l'adresse du serveur sous la forme 192.168.22.102 (mariadb-gw-2). Attendez que le déploiement se termine pour les deux nœuds HAProxy.

Nous devons maintenant configurer le service HAProxy sur mariadb-gw-1 et mariadb-gw-2 pour équilibrer la charge de tous les fragments à la fois. À l'aide de l'éditeur de texte (ou de l'interface utilisateur de ClusterControl > Gérer > Configurations), modifiez les 2 dernières directives "écouter" du fichier /etc/haproxy/haproxy.cfg pour qu'elles ressemblent à ceci :

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

Redémarrez le service HAProxy pour charger les modifications (ou utilisez ClusterControl -> Nodes -> HAProxy -> Restart Node) :

$ systemctl restart haproxy

Depuis l'interface utilisateur de ClusterControl, nous pouvons vérifier qu'un seul serveur principal est actif par partition (indiqué par les lignes vertes), comme indiqué ci-dessous :

À ce stade, le déploiement de notre cluster de base de données est maintenant terminé. Nous pouvons procéder à la configuration du partitionnement MariaDB à l'aide du moteur de stockage Spider.

Préparation des serveurs de passerelle MariaDB

Sur les deux serveurs MariaDB Gateway (mariadb-gw-1 et mariadb-gw-2), effectuez les tâches suivantes :

Installer le plug-in Spider :

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

Vérifiez si le moteur de stockage est pris en charge :

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

En option, nous pouvons également vérifier si le plugin est correctement chargé à partir de la base de données information_schema :

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 |
+--------------------------+----------------+---------------+--------------------+

Ajoutez la ligne suivante sous la section [mysqld] dans le fichier de configuration MariaDB :

plugin-load-add = ha_spider

Créez le premier "nœud de données" pour le premier fragment qui devrait être accessible via HAProxy 127.0.0.1 sur le port 3307 :

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

Créez le deuxième "nœud de données" pour le deuxième fragment qui devrait être accessible via HAProxy 127.0.0.1 sur le port 3308 :

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

Nous pouvons maintenant créer une table Spider qui doit être partitionnée. Dans cet exemple, nous allons créer une table appelée sbtest1 dans la base de données sbtest, et partitionnée par la valeur entière dans la colonne '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"'
);

Notez que les clauses COMMENT ='srv "ShardX"' de l'instruction CREATE TABLE sont essentielles, où nous transmettons les informations de connexion sur le serveur distant. La valeur doit être identique au nom du serveur comme dans l'instruction CREATE SERVER. Nous allons remplir ce tableau à l'aide du générateur de charge Sysbench comme indiqué ci-dessous.

Créez l'utilisateur de la base de données d'application pour accéder à la base de données et autorisez-le depuis les serveurs d'application :

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

Dans cet exemple, puisqu'il s'agit d'un réseau interne de confiance, nous utilisons simplement un caractère générique dans la déclaration pour autoriser toute adresse IP dans la même plage, 192.168.22.0/24.

Nous sommes maintenant prêts à configurer nos nœuds de données.

Préparation des serveurs de fragments MariaDB

Sur les deux serveurs maîtres MariaDB Shard (mariadb-shard-1a et mariadb-shard-2a), effectuez les tâches suivantes :

1) Créez la base de données de destination :

MariaDB> CREATE SCHEMA sbtest;

2) Créez l'utilisateur 'spider' et autorisez les connexions depuis les serveurs de passerelle (mariadb-gw-1 et mariadb-gw2). Cet utilisateur doit avoir tous les privilèges sur la table partitionnée ainsi que sur la base de données système MySQL :

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.%';

Dans cet exemple, puisqu'il s'agit d'un réseau interne de confiance, nous utilisons simplement un caractère générique dans la déclaration pour autoriser toute adresse IP dans la même plage, 192.168.22.0/24.

3) Créez la table qui va recevoir les données de nos serveurs de passerelle via le moteur de stockage Spider. Cette table "récepteur" peut être sur n'importe quel moteur de stockage pris en charge par MariaDB. Dans cet exemple, nous utilisons le moteur de stockage InnoDB :

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;

C'est tout. N'oubliez pas de répéter les étapes sur l'autre fragment.

Tests

Pour tester l'utilisation de Sysbench pour générer certaines charges de travail de base de données, sur le serveur d'application, nous devons installer Sysbench au préalable :

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

Générez des charges de travail de test et envoyez-les au premier serveur de passerelle, 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

Vous pouvez répéter le test ci-dessus sur mariadb-gw-2 (192.168.11.102) et les connexions à la base de données doivent être acheminées vers le bon fragment en conséquence.

En regardant le premier fragment (mariadb-shard-1a ou mariadb-shard-1b), nous pouvons dire que cette partition ne contient que des lignes où la clé de fragment (colonne k) est inférieure à 500 000 :

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

Sur un autre fragment (mariadb-shard-2a ou mariadb-shard-2b), il contient les données de 500000 jusqu'à 999999 comme prévu :

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

Alors que pour le serveur MariaDB Gateway (mariadb-gw-1 ou mariadb-gw-2), nous pouvons voir toutes les lignes comme si la table existe dans cette instance MariaDB :

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

Pour tester l'aspect haute disponibilité, lorsqu'un maître de partition n'est pas disponible, par exemple lorsque le maître (mariadb-shard-2a) de la partition 2 tombe en panne, ClusterControl effectuera automatiquement la promotion de l'esclave sur l'esclave (mariadb-shard-2b) pour être un maître. Pendant cette période, vous pourriez probablement voir cette erreur :

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

Et pendant son indisponibilité, vous obtiendrez l'erreur suivante :

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

Dans notre mesure, le basculement a pris environ 23 secondes après le début du basculement et une fois le nouveau maître promu, vous devriez pouvoir écrire dans la table à partir du serveur de passerelle comme d'habitude.

Conclusion

La configuration ci-dessus est une preuve de principe sur la façon dont ClusterControl peut être utilisé pour déployer une configuration partitionnée MariaDB. Il peut également améliorer la disponibilité du service d'une configuration de partitionnement MariaDB avec sa fonctionnalité de récupération automatique des nœuds et des clusters, ainsi que toutes les fonctionnalités de gestion et de surveillance standard de l'industrie pour prendre en charge votre infrastructure de base de données globale.