Nasazení MariaDB Sharding s Spider pomocí ClusterControl

MariaDB nabízí vestavěné možnosti sdílení více hostitelů pomocí úložiště Spider. Spider podporuje dělení a transakce XA a umožňuje zpracování vzdálených tabulek různých instancí MariaDB, jako by byly ve stejné instanci. Vzdálený stůl může být z libovolného úložiště. Propojení tabulek je dosaženo vytvořením připojení z místního serveru MariaDB ke vzdálenému serveru MariaDB a odkaz je sdílen pro všechny tabulky, které jsou součástí stejné transakce.

V tomto příspěvku na blogu vás provedeme nasazením clusteru dvou fragmentů MariaDB pomocí ClusterControl. Chystáme se nasadit několik serverů MariaDB (kvůli redundanci a dostupnosti) k hostování rozdělené tabulky na základě rozsahu vybraného shard klíče. Zvolený zlomkový klíč je v podstatě sloupec, který ukládá hodnoty s dolním a horním limitem, jako v tomto případě, celočíselné hodnoty mezi 0 až 1 000 000, což z něj činí nejlepší kandidátský klíč pro vyvážení distribuce dat mezi dvěma fragmenty. Proto rozdělíme rozsahy do dvou oddílů:

• 0 – 499999:Shard 1

• 500000 – 1000000:Shard 2

Následující diagram ilustruje naši architekturu na vysoké úrovni toho, co se chystáme nasadit:

Některá vysvětlení diagramu:

1. mariadb-gw-1:Instance MariaDB, která provozuje úložiště Spider, funguje jako směrovač fragmentů. Tomuto hostiteli dáváme jméno jako MariaDB Gateway 1 a toto bude primární (aktivní) server MariaDB, který dosáhne úlomků. Aplikace se připojí k tomuto hostiteli jako standardní připojení MariaDB. Tento uzel se připojuje k fragmentům prostřednictvím HAProxy naslouchajícího na portech 127.0.0.1 3307 (shard1) a 3308 (shard2).

2. mariadb-gw-2:Instance MariaDB, která provozuje úložiště Spider, funguje jako směrovač fragmentů. Tomuto hostiteli dáváme jméno jako MariaDB Gateway 2 a toto bude sekundární (pasivní) server MariaDB, který dosáhne úlomků. Bude mít stejné nastavení jako mariadb-gw-1. Aplikace se k tomuto hostiteli připojí pouze v případě, že primární MariaDB nefunguje. Tento uzel se připojuje k fragmentům prostřednictvím HAProxy naslouchajícího na portech 127.0.0.1 3307 (shard1) a 3308 (shard2).

3. mariadb-shard-1a:Hlavní server MariaDB, který slouží jako primární datový uzel pro první oddíl. Servery brány MariaDB by měly zapisovat pouze do hlavního serveru fragmentu.

4. mariadb-shard-1b:replika MariaDB, která slouží jako sekundární datový uzel pro první oddíl. Převezme hlavní roli v případě, že hlavní server fragmentu selže (automatické převzetí služeb při selhání je řízeno ClusterControl).

5. mariadb-shard-2a:Hlavní server MariaDB, který slouží jako primární datový uzel pro druhý oddíl. Servery brány MariaDB zapisují pouze do hlavního serveru fragmentu.

6. mariadb-shard-2b:replika MariaDB, která slouží jako sekundární datový uzel pro druhý oddíl. Převezme hlavní roli v případě, že hlavní server fragmentu selže (automatické převzetí služeb při selhání je řízeno ClusterControl).

7. ClusterControl:Centralizovaný nástroj pro nasazení, správu a monitorování pro naše fragmenty/klastry MariaDB.

Nasazení databázových clusterů pomocí ClusterControl

ClusterControl je automatizační nástroj pro správu životního cyklu vašeho systému správy databází s otevřeným zdrojovým kódem. Pro účely tohoto blogového příspěvku budeme používat ClusterControl jako centralizovaný nástroj pro nasazení clusteru, správu topologie a monitorování.

1) Nainstalujte ClusterControl.

2) Nakonfigurujte SSH bez hesla ze serveru ClusterControl do všech databázových uzlů. V uzlu 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) Vzhledem k tomu, že se chystáme nasadit 4 sady clusterů, je vhodné pro tento konkrétní úkol použít nástroj ClusterControl CLI, aby se proces nasazení urychlil a zjednodušil. Nejprve ověřte, zda se můžeme připojit s výchozími přihlašovacími údaji spuštěním následujícího příkazu (výchozí přihlašovací údaje jsou automaticky konfigurovány v /etc/s9s.conf):

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

Pokud neobjevíme žádné chyby a uvidíme podobný výstup jako výše, můžeme začít.

4) Všimněte si, že kroky 4, 5, 6 a 7 lze provést najednou, protože ClusterControl podporuje paralelní nasazení. Začneme nasazením prvního serveru MariaDB Gateway pomocí 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) Nasaďte druhý server 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) Nasaďte 2uzlovou replikaci MariaDB pro první 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) Nasaďte 2uzlovou replikaci MariaDB pro druhý 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"

Zatímco nasazování probíhá, můžeme sledovat výstup úlohy z 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

A také z uživatelského rozhraní ClusterControl:

Po dokončení nasazení byste měli vidět seznam databázových clusterů takto v řídicím panelu ClusterControl:

Naše clustery jsou nyní nasazeny a běží na nich nejnovější MariaDB 10.5. Dále musíme nakonfigurovat HAProxy tak, aby poskytovalo jeden koncový bod fragmentům MariaDB.

Nakonfigurujte HAProxy

HAProxy je nezbytný jako jediný koncový bod replikace master-slave fragmentu. V opačném případě, pokud selže hlavní server, je nutné aktualizovat seznam serverů Spider pomocí příkazu CREATE OR REPLACE SERVER na serverech brány a provést ALTER TABLE a předat nový parametr připojení. S HAProxy jej můžeme nakonfigurovat tak, aby naslouchal na místním hostiteli serveru brány a sledoval různé fragmenty MariaDB s různými porty. Nakonfigurujeme HAProxy na obou serverech brány následovně:

• 127.0.0.1:3307 -> Shard1 (backendové servery jsou mariadb-shard-1a a mariadb-shard- 1b)

• 127.0.0.1:3308 -> Shard2 (backendové servery jsou mariadb-shard-2a a mariadb-shard- 2b)

V případě, že hlavní server fragmentu selže, ClusterControl převezme selhání podřízeného fragmentu jako nového hlavního serveru a HAProxy podle toho přesměruje připojení k novému hlavnímu serveru. Chystáme se nainstalovat HAProxy na servery brány (mariadb-gw-1 a mariadb-gw-2) pomocí ClusterControl, protože automaticky nakonfiguruje backend servery (nastavení mysqlchk, uživatelské granty, instalace xinetd) pomocí několika triků, jak je uvedeno níže.

Nejprve v uživatelském rozhraní ClusterControl vyberte první fragment, MariaDB - Shard 1 -> Manage -> Load Balancers -> HAProxy -> Deploy HAProxy a zadejte adresu serveru jako 192.168.22.101 ( mariadb-gw-1), podobný následujícímu snímku obrazovky:

Podobně, ale tento pro shard 2, přejděte na MariaDB - Shard 2 -> Spravovat -> Load Balancers -> HAProxy -> Nasadit HAProxy a zadat adresu serveru jako 192.168.22.102 (mariadb-gw-2). Počkejte na dokončení nasazení pro oba uzly HAProxy.

Nyní musíme nakonfigurovat službu HAProxy na mariadb-gw-1 a mariadb-gw-2 tak, aby vyvažovala zatížení všech shardů najednou. Pomocí textového editoru (nebo uživatelského rozhraní ClusterControl -> Spravovat -> Konfigurace) upravte poslední 2 direktivy "listen" souboru /etc/haproxy/haproxy.cfg tak, aby vypadaly takto:

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

Restartujte službu HAProxy, aby se načetly změny (nebo použijte ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

Z uživatelského rozhraní ClusterControl můžeme ověřit, že je aktivní pouze jeden backend server na datový fragment (označeno zelenými čarami), jak je znázorněno níže:

V tuto chvíli je nasazení našeho databázového clusteru dokončeno. Můžeme přistoupit ke konfiguraci sdílení MariaDB pomocí úložiště Spider.

Příprava serverů brány MariaDB

Na obou serverech MariaDB Gateway (mariadb-gw-1 a mariadb-gw-2) proveďte následující úkoly:

Instalovat plugin Spider:

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

Ověřte, zda je úložiště podporováno:

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

Volitelně můžeme také ověřit, zda je plugin správně načten z databáze 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 |
+--------------------------+----------------+---------------+--------------------+

Přidejte následující řádek do sekce [mysqld] v konfiguračním souboru MariaDB:

plugin-load-add = ha_spider

Vytvořte první "datový uzel" pro první fragment, který by měl být přístupný přes HAProxy 127.0.0.1 na portu 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);

Vytvořte druhý „datový uzel“ pro druhý fragment, který by měl být přístupný přes HAProxy 127.0.0.1 na portu 3308:

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

Nyní můžeme vytvořit Spider tabulku, kterou je třeba rozdělit. V tomto příkladu vytvoříme tabulku nazvanou sbtest1 uvnitř databáze sbtest a rozdělenou podle celočíselné hodnoty ve sloupci '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"'
);

Všimněte si, že klauzule COMMENT ='srv "ShardX"' příkazu CREATE TABLE jsou kritické, kde předáváme informace o připojení ke vzdálenému serveru. Hodnota musí být shodná s názvem serveru jako v příkazu CREATE SERVER. Tuto tabulku vyplníme pomocí generátoru zatížení Sysbench, jak je uvedeno níže.

Vytvořte uživatele databáze aplikace pro přístup k databázi a povolte mu přístup z aplikačních serverů:

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

V tomto příkladu, protože se jedná o důvěryhodnou interní síť, použijeme v příkazu pouze zástupný znak, abychom povolili jakoukoli IP adresu ve stejném rozsahu, 192.168.22.0/24.

Nyní jsme připraveni nakonfigurovat naše datové uzly.

Příprava serverů MariaDB Shard

Na obou hlavních serverech MariaDB Shard (mariadb-shard-1a a mariadb-shard-2a) proveďte následující úkoly:

1) Vytvořte cílovou databázi:

MariaDB> CREATE SCHEMA sbtest;

2) Vytvořte uživatele 'spider' a povolte připojení ze serverů brány (mariadb-gw-1 a mariadb-gw2). Tento uživatel musí mít všechna oprávnění pro sdílenou tabulku a také systémovou databázi 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.%';

V tomto příkladu, protože se jedná o důvěryhodnou interní síť, použijeme v příkazu pouze zástupný znak, abychom povolili jakoukoli IP adresu ve stejném rozsahu, 192.168.22.0/24.

3) Vytvořte tabulku, která bude přijímat data z našich serverů brány prostřednictvím úložiště Spider. Tato tabulka „přijímače“ může být na libovolném úložišti podporovaném MariaDB. V tomto příkladu používáme úložiště 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;

To je vše. Nezapomeňte zopakovat kroky na druhém úlomku.

Testování

Chceme-li otestovat použití Sysbench ke generování některých databázových úloh, na aplikačním serveru musíme Sysbench předem nainstalovat:

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

Vygenerujte nějaké testovací úlohy a odešlete je na první server brány, 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

Výše uvedený test můžete zopakovat na mariadb-gw-2 (192.168.11.102) a databázová připojení by měla být podle toho směrována na správný fragment.

Když se podíváme na první fragment (mariadb-shard-1a nebo mariadb-shard-1b), můžeme říci, že tento oddíl obsahuje pouze řádky, kde je klíč fragmentu (sloupec k) menší než 500 000:

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

Na jiném datovém fragmentu (mariadb-shard-2a nebo mariadb-shard-2b) uchovává data od 500 000 až do 999999 podle očekávání:

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

Zatímco pro server MariaDB Gateway (mariadb-gw-1 nebo mariadb-gw-2), můžeme vidět všechny řádky podobné tomu, pokud tabulka existuje uvnitř této instance MariaDB:

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

Chcete-li otestovat aspekt vysoké dostupnosti, když není k dispozici hlavní útržek, například když hlavní (mariadb-shard-2a) úlomku 2 selže, ClusterControl automaticky provede povýšení slave na otrok (mariadb-shard-2b) být pánem. Během tohoto období se pravděpodobně může zobrazit tato chyba:

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

A když je nedostupný, zobrazí se následující chyba:

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

Při našem měření trvalo převzetí služeb při selhání přibližně 23 sekund po zahájení převzetí služeb při selhání a po povýšení nového hlavního serveru byste měli být schopni zapisovat do tabulky ze serveru brány jako obvykle.

Závěr

Výše uvedené nastavení je důkazem principu toho, jak lze ClusterControl použít k nasazení shardovaného nastavení MariaDB. Může také zlepšit dostupnost služeb nastavení shardingu MariaDB pomocí funkce automatického obnovení uzlů a clusteru a všech standardních funkcí správy a monitorování pro podporu vaší celkové databázové infrastruktury.