sql >> Databasteknik >  >> RDS >> MariaDB

Distribuera MariaDB Sharding med Spider med ClusterControl

MariaDB erbjuder inbyggda multi-host shading-funktioner med Spider-lagringsmotorn. Spider stöder partitionering och XA-transaktioner och tillåter att fjärrtabeller för olika MariaDB-instanser hanteras som om de var på samma instans. Fjärrbordet kan vara av vilken lagringsmotor som helst. Tabelllänkningen uppnås genom upprättandet av anslutningen från en lokal MariaDB-server till en fjärransluten MariaDB-server, och länken delas för alla tabeller som ingår i samma transaktion.

I det här blogginlägget kommer vi att leda dig genom distributionen av ett kluster av två MariaDB-skärvor med ClusterControl. Vi kommer att distribuera en handfull MariaDB-servrar (för redundans och tillgänglighet) för att vara värd för en partitionerad tabell baserat på ett intervall av en vald shard-nyckel. Den valda shardnyckeln är i grunden en kolumn som lagrar värden med en nedre och övre gräns, som i det här fallet, heltalsvärden mellan 0 och 1 000 000, vilket gör den till den bästa kandidatnyckeln för att balansera datafördelning mellan två shards. Därför kommer vi att dela upp intervallen i två partitioner:

  • 0 - 499999:Shard 1

  • 500000 - 1000000:Shard 2

Följande diagram illustrerar vår högnivåarkitektur för vad vi ska distribuera:

Några förklaringar av diagrammet:

  1. mariadb-gw-1:MariaDB-instans som kör Spider-lagringsmotorn fungerar som en shard-router. Vi ger denna värd ett namn som MariaDB Gateway 1 och detta kommer att vara den primära (aktiva) MariaDB-servern för att nå skärvorna. Applikationen kommer att ansluta till denna värd som en standard MariaDB-anslutning. Denna nod ansluter till skärvorna via HAProxy-lyssning på 127.0.0.1-portarna 3307 (shard1) och 3308 (shard2).

  2. mariadb-gw-2:MariaDB-instans som kör Spider-lagringsmotorn fungerar som en shard-router. Vi ger denna värd ett namn som MariaDB Gateway 2 och detta kommer att bli den sekundära (passiva) MariaDB-servern för att nå skärvorna. Den kommer att ha samma inställning som mariadb-gw-1. Applikationen kommer endast att ansluta till denna värd om den primära MariaDB är nere. Denna nod ansluter till skärvorna via HAProxy-lyssning på 127.0.0.1-portarna 3307 (shard1) och 3308 (shard2).

  3. mariadb-shard-1a:MariaDB-master som fungerar som den primära datanoden för den första partitionen. MariaDB-gatewayservrar ska bara skriva till skärvans master.

  4. mariadb-shard-1b:MariaDB-replik som fungerar som sekundär datanod för den första partitionen. Den ska ta över huvudrollen om skärvans master går ner (automatisk failover hanteras av ClusterControl).

  5. mariadb-shard-2a:MariaDB-master som fungerar som primär datanod för den andra partitionen. MariaDB-gatewayservrar skriver bara till skärvans master.

  6. mariadb-shard-2b:MariaDB-replik som fungerar som sekundär datanod för den andra partitionen. Den ska ta över huvudrollen om skärvans master går ner (automatisk failover hanteras av ClusterControl).

  7. ClusterControl:Ett centraliserat verktyg för distribution, hantering och övervakning av våra MariaDB-skärvor/kluster.

Distribuera databaskluster med ClusterControl

ClusterControl är ett automationsverktyg för att hantera livscykeln för ditt databashanteringssystem med öppen källkod. Vi kommer att använda ClusterControl som ett centraliserat verktyg för klusterinstallationer, topologihantering och övervakning i syftet med detta blogginlägg.

1) Installera ClusterControl.

2) Konfigurera den lösenordslösa SSH från ClusterControl-servern till alla databasnoder. På ClusterControl-noden:

(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) Eftersom vi kommer att distribuera 4 uppsättningar kluster är det en bra idé att använda ClusterControl CLI-verktyget för just denna uppgift för att påskynda och förenkla distributionsprocessen. Låt oss först verifiera om vi kan ansluta till standardinloggningsuppgifterna genom att köra följande kommando (standardinloggningsuppgifter konfigureras automatiskt på /etc/s9s.conf):

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

Om vi ​​inte får några fel och ser en liknande utdata som ovan är vi redo.

4) Observera att steg 4,5,6 och 7 kan köras på en gång eftersom ClusterControl stöder parallell distribution. Vi börjar med att distribuera den första MariaDB Gateway-servern med 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) Distribuera den andra MariaDB Gateway-servern:

(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) Distribuera en MariaDB-replikering med 2 noder för den första skärpan:

(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) Distribuera en MariaDB-replikering med 2 noder för den andra skärpan:

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

Medan distributionen pågår kan vi övervaka jobbutdata från 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

Och även från ClusterControl-gränssnittet:

När distributionen är klar bör du se något som databasklustren är listade så här i ClusterControl-instrumentpanelen:

Våra kluster är nu distribuerade och kör den senaste MariaDB 10.5. Därefter måste vi konfigurera HAProxy för att tillhandahålla en enda slutpunkt till MariaDB-skärvorna.

Konfigurera HAProxy

HAProxy är nödvändig som en enda slutpunkt för skärvans master-slave replikering. Annars, om en master går ner, måste man uppdatera Spiders serverlista med hjälp av CREATE OR REPLACE SERVER-satsen i gatewayservrarna, och utföra ALTER TABLE och skicka en ny anslutningsparameter. Med HAProxy kan vi konfigurera den för att lyssna på den lokala värden för gatewayservern och övervaka olika MariaDB-skärvor med olika portar. Vi kommer att konfigurera HAProxy på båda gatewayservrarna enligt följande:

  • 127.0.0.1:3307 -> Shard1 (backend-servrar är mariadb-shard-1a och mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (backend-servrar är mariadb-shard-2a och mariadb-shard- 2b)

Om skärvans master går ner kommer ClusterControl att failover skärvans slav eftersom den nya mastern och HAProxy kommer att omdirigera anslutningarna till den nya mastern. Vi kommer att installera HAProxy på gatewayservrarna (mariadb-gw-1 och mariadb-gw-2) med ClusterControl eftersom det automatiskt kommer att konfigurera backend-servrarna (mysqlchk-installation, användarbeviljande, xinetd-installation) med några knep som visas nedan.

Först av allt, på ClusterControl-gränssnittet, välj den första shard, MariaDB - Shard 1 -> Hantera -> Load Balancers -> HAProxy -> Deploy HAProxy och ange serveradressen som 192.168.22.101 ( mariadb-gw-1), liknande följande skärmdump:

På liknande sätt, men den här för shard 2, gå till MariaDB - Shard 2 -> Hantera -> Lastbalanserare -> HAProxy -> Deploy HAProxy och ange serveradressen som 192.168.22.102 (mariadb-gw-2). Vänta tills distributionen är klar för båda HAProxy-noderna.

Nu måste vi konfigurera HAProxy-tjänsten på mariadb-gw-1 och mariadb-gw-2 för att lastbalansera alla shards på en gång. Använd textredigeraren (eller ClusterControl UI -> Hantera -> Konfigurationer), redigera de två sista "lyssna"-direktiven i /etc/haproxy/haproxy.cfg så att de ser ut så här:

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

Starta om HAProxy-tjänsten för att ladda ändringarna (eller använd ClusterControl -> Noder -> HAProxy -> Starta om nod):

$ systemctl restart haproxy

Från ClusterControl UI kan vi verifiera att endast en backend-server är aktiv per shard (indikerat med de gröna linjerna), som visas nedan:

Vid denna tidpunkt är implementeringen av vår databaskluster nu klar. Vi kan fortsätta att konfigurera MariaDB-skärningen med Spider-lagringsmotorn.

Förbereder MariaDB Gateway-servrar

Utför följande uppgifter på båda MariaDB Gateway-servrarna (mariadb-gw-1 och mariadb-gw-2:

Installera Spider-plugin:

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

Verifiera om lagringsmotorn stöds:

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

Valfritt kan vi också verifiera om plugin-programmet är korrekt laddat från informationsschemadatabasen:

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

Lägg till följande rad under avsnittet [mysqld] i MariaDB-konfigurationsfilen:

plugin-load-add = ha_spider

Skapa den första "datanoden" för den första shard som ska vara tillgänglig via HAProxy 127.0.0.1 på 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);

Skapa den andra "datanoden" för den andra skärvan som bör vara tillgänglig via HAProxy 127.0.0.1 på 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);

Nu kan vi skapa en Spider-tabell som behöver partitioneras. I det här exemplet kommer vi att skapa en tabell som heter sbtest1 inuti databasen sbtest, och partitionerad med heltalsvärdet i kolumnen '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"'
);

Observera att COMMENT ='srv "ShardX"'-satserna i CREATE TABLE-satsen är kritiska, där vi skickar anslutningsinformation om fjärrservern. Värdet måste vara identiskt med servernamnet som i CREATE SERVER-satsen. Vi kommer att fylla i den här tabellen med hjälp av Sysbench-lastgeneratorn som visas längre ner.

Skapa applikationsdatabasenanvändaren för att komma åt databasen och tillåt den från applikationsservrarna:

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

I det här exemplet, eftersom detta är ett pålitligt internt nätverk, använder vi bara ett jokertecken i satsen för att tillåta vilken IP-adress som helst inom samma intervall, 192.168.22.0/24.

Vi är nu redo att konfigurera våra datanoder.

Förbereder MariaDB Shard-servrar

På båda MariaDB Shard-huvudservrarna (mariadb-shard-1a och mariadb-shard-2a), utför följande uppgifter:

1) Skapa måldatabasen:

MariaDB> CREATE SCHEMA sbtest;

2) Skapa 'spider'-användaren och tillåt anslutningar från gatewayservrarna (mariadb-gw-1 och mariadb-gw2). Denna användare måste ha alla privilegier på den sönderdelade tabellen och även MySQL-systemdatabasen:

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

I det här exemplet, eftersom detta är ett pålitligt internt nätverk, använder vi bara ett jokertecken i satsen för att tillåta vilken IP-adress som helst inom samma intervall, 192.168.22.0/24.

3) Skapa tabellen som kommer att ta emot data från våra gatewayservrar via Spider-lagringsmotorn. Denna "mottagare"-tabell kan vara på vilken lagringsmotor som helst som stöds av MariaDB. I det här exemplet använder vi InnoDB lagringsmotor:

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;

Det var allt. Glöm inte att upprepa stegen på den andra skärpan.

Tester

För att testa att använda Sysbench för att generera vissa databasarbetsbelastningar på applikationsservern måste vi installera Sysbench i förväg:

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

Generera några testarbetsbelastningar och skicka dem till den första gatewayservern, 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

Du kan upprepa ovanstående test på mariadb-gw-2 (192.168.11.102) och databasanslutningarna bör dirigeras till rätt skärva i enlighet med detta.

När vi tittar på den första shard (mariadb-shard-1a eller mariadb-shard-1b), kan vi se att denna partition bara innehåller rader där shard-nyckeln (kolumn k) är mindre än 500000:

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

På en annan skärva (mariadb-shard-2a eller mariadb-shard-2b) innehåller den data från 500000 upp till 999999 som förväntat:

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

Medan för MariaDB Gateway-server (mariadb-gw-1 eller mariadb-gw-2), kan vi se alla rader som liknar om tabellen finns i denna MariaDB-instans:

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

För att testa den höga tillgänglighetsaspekten, när en shard master inte är tillgänglig, till exempel när mastern (mariadb-shard-2a) för shard 2 går ner, kommer ClusterControl automatiskt att utföra slavkampanjen på slaven (mariadb-shard-2b) att vara en mästare. Under denna period kan du förmodligen se detta fel:

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

Och medan den inte är tillgänglig kommer du att få följande felmeddelande:

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

I vår mätning tog failover cirka 23 sekunder efter att failover hade påbörjats och när den nya mastern har befordrats bör du kunna skriva in i tabellen från gatewayservern som vanligt.

Slutsats

Inställningen ovan är ett principbevis på hur ClusterControl kan användas för att distribuera en MariaDB-delad installation. Det kan också förbättra tjänsttillgängligheten för en MariaDB-sharding-installation med dess automatiska nod- och klusteråterställningsfunktion, plus alla branschstandardiserade hanterings- och övervakningsfunktioner för att stödja din övergripande databasinfrastruktur.


  1. Bevilja alla på ett specifikt schema i db till en grupproll i PostgreSQL

  2. Hur kan jag logga och hitta de dyraste frågorna?

  3. Hur man formaterar datum i Oracle

  4. SQL Server strängfunktioner (fullständig lista)