sql >> Database >  >> RDS >> MariaDB

MariaDB Sharding met Spider implementeren met ClusterControl

MariaDB biedt ingebouwde multi-host sharding-mogelijkheden met de Spider-opslagengine. Spider ondersteunt partitionering en XA-transacties en zorgt ervoor dat externe tabellen van verschillende MariaDB-instanties kunnen worden behandeld alsof ze zich op dezelfde instantie bevinden. De externe tafel kan van elke opslagengine zijn. De tabelkoppeling wordt bereikt door de verbinding tot stand te brengen van een lokale MariaDB-server naar een externe MariaDB-server en de koppeling wordt gedeeld voor alle tabellen die deel uitmaken van dezelfde transactie.

In deze blogpost gaan we u door de implementatie van een cluster van twee MariaDB-shards leiden met behulp van ClusterControl. We gaan een handvol MariaDB-servers implementeren (voor redundantie en beschikbaarheid) om een ​​gepartitioneerde tabel te hosten op basis van een bereik van een geselecteerde shardsleutel. De gekozen Shard-sleutel is in feite een kolom die waarden opslaat met een onder- en bovengrens, zoals in dit geval gehele waarden tussen 0 en 1.000.000, waardoor het de beste kandidaat-sleutel is om de gegevensdistributie tussen twee shards in evenwicht te brengen. Daarom verdelen we de bereiken in twee partities:

  • 0 - 499999:Scherf 1

  • 500000 - 1000000:Scherf 2

Het volgende diagram illustreert onze architectuur op hoog niveau van wat we gaan implementeren:

Enkele uitleg van het diagram:

  1. mariadb-gw-1:MariaDB-instantie die de Spider-opslagengine uitvoert, werkt als een shard-router. We geven deze host een naam als MariaDB Gateway 1 en dit wordt de primaire (actieve) MariaDB-server om de shards te bereiken. De applicatie maakt verbinding met deze host als een standaard MariaDB-verbinding. Dit knooppunt maakt verbinding met de shards via HAProxy die luistert op 127.0.0.1-poorten 3307 (shard1) en 3308 (shard2).

  2. mariadb-gw-2:MariaDB-instantie die de Spider-opslagengine uitvoert, werkt als een shard-router. We geven deze host een naam als MariaDB Gateway 2 en dit wordt de secundaire (passieve) MariaDB-server om de shards te bereiken. Het zal dezelfde setup hebben als mariadb-gw-1. De applicatie maakt alleen verbinding met deze host als de primaire MariaDB niet beschikbaar is. Dit knooppunt maakt verbinding met de shards via HAProxy die luistert op 127.0.0.1-poorten 3307 (shard1) en 3308 (shard2).

  3. mariadb-shard-1a:MariaDB-master die dient als het primaire gegevensknooppunt voor de eerste partitie. MariaDB-gatewayservers mogen alleen naar de master van de shard schrijven.

  4. mariadb-shard-1b:MariaDB-replica die dient als secundair gegevensknooppunt voor de eerste partitie. Het neemt de masterrol over in het geval dat de master van de shard uitvalt (automatische failover wordt beheerd door ClusterControl).

  5. mariadb-shard-2a:MariaDB-master die dient als primair gegevensknooppunt voor de tweede partitie. MariaDB-gatewayservers schrijven alleen naar de master van de shard.

  6. mariadb-shard-2b:MariaDB-replica die dient als secundair gegevensknooppunt voor de tweede partitie. Het neemt de masterrol over in het geval dat de master van de shard uitvalt (automatische failover wordt beheerd door ClusterControl).

  7. ClusterControl:een gecentraliseerde tool voor implementatie, beheer en monitoring voor onze MariaDB-shards/clusters.

Databaseclusters implementeren met ClusterControl

ClusterControl is een automatiseringstool om de levenscyclus van uw open-source databasebeheersysteem te beheren. We gaan ClusterControl gebruiken als een gecentraliseerde tool voor clusterimplementaties, topologiebeheer en monitoring voor het doel van deze blogpost.

1) Installeer ClusterControl.

2) Configureer de wachtwoordloze SSH van de ClusterControl-server naar alle databaseknooppunten. Op het ClusterControl-knooppunt:

(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) Aangezien we 4 sets clusters gaan implementeren, is het een goed idee om de ClusterControl CLI-tool voor deze specifieke taak te gebruiken om het implementatieproces te versnellen en te vereenvoudigen. Laten we eerst controleren of we verbinding kunnen maken met de standaardreferenties door de volgende opdracht uit te voeren (standaardreferentie wordt automatisch geconfigureerd in /etc/s9s.conf):

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

Als we geen fouten krijgen en een vergelijkbare uitvoer zien als hierboven, zijn we klaar om te gaan.

4) Merk op dat stappen 4,5,6 en 7 tegelijk kunnen worden uitgevoerd, aangezien ClusterControl parallelle implementatie ondersteunt. We beginnen met het implementeren van de eerste MariaDB Gateway-server met behulp van 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) Implementeer de tweede MariaDB Gateway-server:

(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) Implementeer een 2-node MariaDB-replicatie voor de eerste shard:

(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) Implementeer een 2-node MariaDB-replicatie voor de tweede shard:

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

Terwijl de implementatie aan de gang is, kunnen we de taakuitvoer van CLI volgen:

(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

En ook vanuit de gebruikersinterface van ClusterControl:

Zodra de implementatie is voltooid, zou u iets moeten zien in de databaseclusters zoals dit in het ClusterControl-dashboard:

Onze clusters zijn nu geïmplementeerd en draaien de nieuwste MariaDB 10.5. Vervolgens moeten we HAProxy configureren om een ​​enkel eindpunt te leveren aan de MariaDB-shards.

HAProxy configureren

HAProxy is nodig als een enkel eindpunt voor de master-slave-replicatie van de shard. Anders, als een master uitvalt, moet men de serverlijst van Spider bijwerken met behulp van de instructie CREATE OR REPLACE SERVER in de gatewayservers, en ALTER TABLE uitvoeren en een nieuwe verbindingsparameter doorgeven. Met HAProxy kunnen we het configureren om te luisteren op de lokale host van de gatewayserver en verschillende MariaDB-shards met verschillende poorten te bewaken. We zullen HAProxy op beide gatewayservers als volgt configureren:

  • 127.0.0.1:3307 -> Shard1 (backend-servers zijn mariadb-shard-1a en mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (backend-servers zijn mariadb-shard-2a en mariadb-shard- 2b)

In het geval dat de master van de shard uitvalt, zal ClusterControl de slave van de shard als de nieuwe master een failover geven en zal HAProxy de verbindingen dienovereenkomstig omleiden naar de nieuwe master. We gaan HAProxy installeren op de gatewayservers (mariadb-gw-1 en mariadb-gw-2) met behulp van ClusterControl, omdat het automatisch de backend-servers (mysqlchk-configuratie, gebruikerstoekenningen, xinetd-installatie) zal configureren met enkele trucs zoals hieronder weergegeven.

Kies allereerst in de gebruikersinterface van ClusterControl de eerste shard, MariaDB - Shard 1 -> Beheren -> Load Balancers -> HAProxy -> Implementeer HAProxy en geef het serveradres op als 192.168.22.101 ( mariadb-gw-1), vergelijkbaar met de volgende schermafbeelding:

Ook, maar deze voor Shard 2, ga naar MariaDB - Shard 2 -> Beheren -> Load Balancers -> HAProxy -> Implementeer HAProxy en geef het serveradres op als 192.168.22.102 (mariadb-gw-2). Wacht tot de implementatie is voltooid voor beide HAProxy-knooppunten.

Nu moeten we de HAProxy-service op mariadb-gw-1 en mariadb-gw-2 configureren om alle shards tegelijk te verdelen. Gebruik de teksteditor (of ClusterControl UI -> Beheren -> Configuraties), bewerk de laatste 2 "luister"-richtlijnen van /etc/haproxy/haproxy.cfg om er als volgt uit te zien:

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

Herstart de HAProxy-service om de wijzigingen te laden (of gebruik ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

Vanuit de gebruikersinterface van ClusterControl kunnen we verifiëren dat er slechts één backend-server actief is per shard (aangegeven door de groene lijnen), zoals hieronder weergegeven:

Op dit moment is de implementatie van onze databasecluster voltooid. We kunnen doorgaan met het configureren van de MariaDB-sharding met behulp van de Spider-opslagengine.

MariaDB Gateway Servers voorbereiden

Voer op beide MariaDB Gateway-servers (mariadb-gw-1 en mariadb-gw-2) de volgende taken uit:

Spider-plug-in installeren:

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

Controleer of de opslagengine wordt ondersteund:

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

Optioneel kunnen we ook controleren of de plug-in correct is geladen vanuit de information_schema-database:

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

Voeg de volgende regel toe onder de sectie [mysqld] in het MariaDB-configuratiebestand:

plugin-load-add = ha_spider

Maak het eerste "dataknooppunt" voor de eerste shard die toegankelijk moet zijn via HAProxy 127.0.0.1 op poort 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);

Maak het tweede "gegevensknooppunt" voor de tweede shard die toegankelijk moet zijn via HAProxy 127.0.0.1 op poort 3308:

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

Nu kunnen we een Spider-tabel maken die moet worden gepartitioneerd. In dit voorbeeld gaan we een tabel maken met de naam sbtest1 in database sbtest, en gepartitioneerd door de integerwaarde in de kolom '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"'
);

Merk op dat de COMMENT ='srv "ShardX"'-clausules van de CREATE TABLE-instructie van cruciaal belang zijn, waar we verbindingsinformatie over de externe server doorgeven. De waarde moet identiek zijn aan de servernaam zoals in de instructie CREATE SERVER. We gaan deze tabel vullen met behulp van de Sysbench-laadgenerator, zoals hieronder wordt weergegeven.

Maak de applicatiedatabasegebruiker aan om toegang te krijgen tot de database en sta deze toe vanaf de applicatieservers:

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

In dit voorbeeld, aangezien dit een vertrouwd intern netwerk is, gebruiken we gewoon een jokerteken in de instructie om elk IP-adres in hetzelfde bereik, 192.168.22.0/24, toe te staan.

We zijn nu klaar om onze gegevensknooppunten te configureren.

MariaDB Shard-servers voorbereiden

Voer op beide MariaDB Shard-masterservers (mariadb-shard-1a en mariadb-shard-2a) de volgende taken uit:

1) Maak de doeldatabase:

MariaDB> CREATE SCHEMA sbtest;

2) Maak de 'spider'-gebruiker aan en sta verbindingen toe vanaf de gatewayservers (mariadb-gw-1 en mariadb-gw2). Deze gebruiker moet alle rechten hebben op de shard-tabel en ook op de MySQL-systeemdatabase:

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 dit voorbeeld, aangezien dit een vertrouwd intern netwerk is, gebruiken we gewoon een jokerteken in de instructie om elk IP-adres in hetzelfde bereik, 192.168.22.0/24, toe te staan.

3) Maak de tabel die de gegevens van onze gatewayservers gaat ontvangen via de Spider-opslagengine. Deze "ontvanger"-tabel kan op elke opslag-engine staan ​​die door MariaDB wordt ondersteund. In dit voorbeeld gebruiken we de InnoDB-opslagengine:

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;

Dat is het. Vergeet niet de stappen op de andere scherf te herhalen.

Testen

Om te testen met Sysbench om een ​​aantal database-workloads te genereren, op de applicatieserver, moeten we Sysbench vooraf installeren:

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

Genereer enkele testworkloads en stuur ze naar de eerste gatewayserver, 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

U kunt de bovenstaande test herhalen op mariadb-gw-2 (192.168.11.102) en de databaseverbindingen moeten dienovereenkomstig naar de juiste shard worden gerouteerd.

Als we naar de eerste shard (mariadb-shard-1a of mariadb-shard-1b) kijken, kunnen we zien dat deze partitie alleen rijen bevat waar de shard-sleutel (kolom k) kleiner is dan 500000:

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

Op een andere shard (mariadb-shard-2a of mariadb-shard-2b) bevat het gegevens van 500000 tot 999999 zoals verwacht:

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

Terwijl we voor MariaDB Gateway-server (mariadb-gw-1 of mariadb-gw-2), kunnen we alle rijen zien die lijken op of de tabel bestaat in deze MariaDB-instantie:

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

Als een shardmaster niet beschikbaar is, bijvoorbeeld wanneer de master (mariadb-shard-2a) van shard 2 uitvalt, voert ClusterControl automatisch de slave-promotie uit om te testen op het aspect hoge beschikbaarheid. de slaaf (mariadb-shard-2b) om een ​​meester te zijn. Tijdens deze periode kunt u waarschijnlijk deze fout zien:

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

En hoewel het niet beschikbaar is, krijgt u de volgende foutmelding:

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

In onze meting duurde de failover ongeveer 23 seconden nadat de failover was begonnen en zodra de nieuwe master is gepromoveerd, zou u zoals gewoonlijk in de tabel moeten kunnen schrijven vanaf de gatewayserver.

Conclusie

De bovenstaande setup is een proof of principle van hoe ClusterControl kan worden gebruikt om een ​​MariaDB shard-setup te implementeren. Het kan ook de servicebeschikbaarheid van een MariaDB-shardingconfiguratie verbeteren met zijn automatische node- en clusterherstelfunctie, plus alle industriestandaard beheer- en bewakingsfuncties om uw algehele database-infrastructuur te ondersteunen.


  1. CONSTRAINT om waarden uit een op afstand gerelateerde tabel te controleren (via join etc.)

  2. Hoe kan ik het aantal woorden in een string in Oracle tellen?

  3. sqlite geretourneerd:foutcode =1, msg =geen dergelijke kolom:keuken1

  4. Een opgeslagen procedure uitvoeren in een andere opgeslagen procedure in SQL-server