sql >> Database teknologi >  >> RDS >> MariaDB

Implementering af MariaDB Sharding med Spider ved hjælp af ClusterControl

MariaDB tilbyder indbyggede multi-host-sharding-funktioner med Spider-lagringsmotoren. Spider understøtter partitionering og XA-transaktioner og tillader fjerntabeller af forskellige MariaDB-instanser at blive håndteret, som om de var på samme instans. Fjernbordet kan være af enhver lagermotor. Tabellinkningen opnås ved etablering af forbindelsen fra en lokal MariaDB-server til en ekstern MariaDB-server, og linket deles for alle tabeller, der er en del af den samme transaktion.

I dette blogindlæg vil vi guide dig gennem implementeringen af ​​en klynge af to MariaDB-shards ved hjælp af ClusterControl. Vi vil implementere en håndfuld MariaDB-servere (til redundans og tilgængelighed) til at være vært for en partitioneret tabel baseret på en række af en valgt shard-nøgle. Den valgte shard-nøgle er grundlæggende en kolonne, der gemmer værdier med en nedre og øvre grænse, som i dette tilfælde heltalværdier mellem 0 og 1.000.000, hvilket gør den til den bedste kandidatnøgle til at balancere datafordeling mellem to shards. Derfor vil vi opdele områderne i to partitioner:

  • 0 - 499999:Shard 1

  • 500000 - 1000000:Shard 2

Følgende diagram illustrerer vores højniveauarkitektur af, hvad vi skal implementere:

Nogle forklaringer af diagrammet:

  1. mariadb-gw-1:MariaDB-instans, der kører Spider-lagringsmotor, fungerer som en shard-router. Vi giver denne vært et navn som MariaDB Gateway 1, og dette vil være den primære (aktive) MariaDB-server til at nå shards. Applikationen vil oprette forbindelse til denne vært som en standard MariaDB-forbindelse. Denne node forbindes til shards via HAProxy-lytning på 127.0.0.1-porte 3307 (shard1) og 3308 (shard2).

  2. mariadb-gw-2:MariaDB-instans, der kører Spider-lagringsmotor, fungerer som en shard-router. Vi giver denne vært et navn som MariaDB Gateway 2, og dette bliver den sekundære (passive) MariaDB-server til at nå skårene. Det vil have samme opsætning som mariadb-gw-1. Applikationen vil kun oprette forbindelse til denne vært, hvis den primære MariaDB er nede. Denne node forbindes til shards via HAProxy-lytning på 127.0.0.1-porte 3307 (shard1) og 3308 (shard2).

  3. mariadb-shard-1a:MariaDB-master, der fungerer som den primære dataknude for den første partition. MariaDB gateway-servere bør kun skrive til shard's master.

  4. mariadb-shard-1b:MariaDB-replika, der fungerer som sekundær dataknude for den første partition. Det skal overtage master-rollen i tilfælde af, at shard's master går ned (automatisk failover administreres af ClusterControl).

  5. mariadb-shard-2a:MariaDB-master, der fungerer som primær dataknude for den anden partition. MariaDB gateway-servere skriver kun til shard's master.

  6. mariadb-shard-2b:MariaDB-replika, der fungerer som sekundær dataknude for den anden partition. Det skal overtage master-rollen i tilfælde af, at shard's master går ned (automatisk failover administreres af ClusterControl).

  7. ClusterControl:Et centraliseret implementerings-, administrations- og overvågningsværktøj til vores MariaDB-shards/-klynger.

Implementering af databaseklynger ved hjælp af ClusterControl

ClusterControl er et automatiseringsværktøj til at styre livscyklussen for dit open source-databasestyringssystem. Vi vil bruge ClusterControl som et centraliseret værktøj til klyngeimplementeringer, topologistyring og overvågning til formålet med dette blogindlæg.

1) Installer ClusterControl.

2) Konfigurer den adgangskodeløse SSH fra ClusterControl-serveren til alle databasenoder. 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) Da vi skal implementere 4 sæt klynger, er det en god idé at bruge ClusterControl CLI-værktøjet til denne særlige opgave for at fremskynde og forenkle implementeringsprocessen. Lad os først kontrollere, om vi kan oprette forbindelse til standardoplysningerne ved at køre følgende kommando (standardlegitimationsoplysninger er automatisk konfigureret på /etc/s9s.conf):

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

Hvis vi ikke får nogen fejl og ser et lignende output som ovenfor, er vi klar.

4) Bemærk, at trin 4,5,6 og 7 kan udføres på én gang, da ClusterControl understøtter parallel implementering. Vi starter med at implementere den første MariaDB Gateway-server ved hjælp af 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) Implementer den anden 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) Implementer en 2-node MariaDB-replikering til det første 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) Implementer en 2-node MariaDB-replikering til det andet 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"

Mens udrulningen er i gang, kan vi overvåge joboutputtet fra 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

Og også fra ClusterControl UI:

Når installationen er færdig, bør du se noget, databaseklyngerne er opført på listen som dette i ClusterControl-dashboardet:

Vores klynger er nu implementeret og kører den seneste MariaDB 10.5. Dernæst skal vi konfigurere HAProxy til at levere et enkelt slutpunkt til MariaDB-shards.

Konfigurer HAProxy

HAProxy er nødvendig som et enkelt endepunkt til shard's master-slave-replikering. Ellers, hvis en master går ned, skal man opdatere Spiders serverliste ved at bruge CREATE OR REPLACE SERVER-sætningen i gateway-serverne, og udføre ALTER TABLE og sende en ny forbindelsesparameter. Med HAProxy kan vi konfigurere den til at lytte på den lokale vært på gateway-serveren og overvåge forskellige MariaDB-shards med forskellige porte. Vi konfigurerer HAProxy på begge gateway-servere som følgende:

  • 127.0.0.1:3307 -> Shard1 (backend-servere er mariadb-shard-1a og mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (backend-servere er mariadb-shard-2a og mariadb-shard- 2b)

I tilfælde af at shard's master går ned, vil ClusterControl failover shard's slave, da den nye master og HAProxy vil omdirigere forbindelserne til den nye master i overensstemmelse hermed. Vi skal installere HAProxy på gateway-serverne (mariadb-gw-1 og mariadb-gw-2) ved hjælp af ClusterControl, da det automatisk vil konfigurere backend-serverne (mysqlchk-opsætning, brugerbevillinger, xinetd-installation) med nogle tricks som vist nedenfor.

Først og fremmest, på ClusterControl UI, skal du vælge det første shard, MariaDB - Shard 1 -> Administrer -> Load Balancers -> HAProxy -> Deploy HAProxy og angiv serveradressen som 192.168.22.101 ( mariadb-gw-1), svarende til følgende skærmbillede:

På samme måde, men denne til shard 2, gå til MariaDB - Shard 2 -> Administrer -> Load Balancers -> HAProxy -> Implementer HAProxy og angiv serveradressen som 192.168.22.102 (mariadb-gw-2). Vent, indtil installationen er færdig for begge HAProxy-noder.

Nu skal vi konfigurere HAProxy-tjenesten på mariadb-gw-1 og mariadb-gw-2 for at indlæse alle shards på én gang. Brug teksteditor (eller ClusterControl UI -> Administrer -> Konfigurationer), rediger de sidste 2 "lytte"-direktiver i /etc/haproxy/haproxy.cfg, så de ser sådan ud:

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

Genstart HAProxy-tjenesten for at indlæse ændringerne (eller brug ClusterControl -> Noder -> HAProxy -> Genstart node):

$ systemctl restart haproxy

Fra ClusterControl UI kan vi bekræfte, at kun én backend-server er aktiv pr. shard (angivet med de grønne linjer), som vist nedenfor:

På dette tidspunkt er implementeringen af ​​vores databaseklynge nu fuldført. Vi kan fortsætte med at konfigurere MariaDB-sharding ved hjælp af Spider-lagringsmotoren.

Forberedelse af MariaDB Gateway-servere

Udfør følgende opgaver på begge MariaDB Gateway-servere (mariadb-gw-1 og mariadb-gw-2):

Installer Spider-plugin:

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

Bekræft, om lagringsmotoren er understøttet:

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

Valgfrit kan vi også kontrollere, om pluginnet er indlæst korrekt fra informationsskemadatabasen:

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

Tilføj følgende linje under [mysqld]-sektionen i MariaDB-konfigurationsfilen:

plugin-load-add = ha_spider

Opret den første "dataknude" for det første shard, som skal være tilgængelig 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);

Opret den anden "dataknude" for den anden shard, som skal være tilgængelig 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 oprette en Spider-tabel, der skal partitioneres. I dette eksempel skal vi oprette en tabel kaldet sbtest1 inde i databasen sbtest, og opdelt efter heltalsværdien i kolonnen '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"'
);

Bemærk, at COMMENT ='srv "ShardX"'-sætningerne i CREATE TABLE-sætningen er kritiske, hvor vi videregiver forbindelsesoplysninger om fjernserveren. Værdien skal være identisk med servernavnet som i CREATE SERVER-sætningen. Vi skal udfylde denne tabel ved hjælp af Sysbench-belastningsgeneratoren som vist længere nede.

Opret applikationsdatabasebrugeren for at få adgang til databasen, og tillad den fra applikationsserverne:

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

I dette eksempel, da dette er et betroet internt netværk, bruger vi bare et jokertegn i sætningen for at tillade enhver IP-adresse i samme område, 192.168.22.0/24.

Vi er nu klar til at konfigurere vores data noder.

Forberedelse af MariaDB Shard-servere

Udfør følgende opgaver på begge MariaDB Shard-masterservere (mariadb-shard-1a og mariadb-shard-2a):

1) Opret destinationsdatabasen:

MariaDB> CREATE SCHEMA sbtest;

2) Opret 'spider'-brugeren og tillad forbindelser fra gateway-serverne (mariadb-gw-1 og mariadb-gw2). Denne bruger skal have alle privilegier på den opdelte tabel og også 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 dette eksempel, da dette er et betroet internt netværk, bruger vi bare et jokertegn i sætningen for at tillade enhver IP-adresse i samme område, 192.168.22.0/24.

3) Opret tabellen, der skal modtage dataene fra vores gateway-servere via Spider-lagringsmotor. Denne "modtager"-tabel kan være på enhver lagermotor, der understøttes af MariaDB. I dette eksempel bruger vi InnoDB storage 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;

Det var det. Glem ikke at gentage trinene på det andet skår.

Test

For at teste at bruge Sysbench til at generere nogle database-arbejdsbelastninger på applikationsserveren, skal vi installere Sysbench på forhånd:

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

Generer nogle test-arbejdsbelastninger og send dem til den første 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

Du kan gentage ovenstående test på mariadb-gw-2 (192.168.11.102), og databaseforbindelserne bør derfor dirigeres til den rigtige shard.

Når vi ser på det første shard (mariadb-shard-1a eller mariadb-shard-1b), kan vi se, at denne partition kun indeholder rækker, hvor shard-nøglen (kolonne k) er mindre end 500000:

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

På et andet shard (mariadb-shard-2a eller mariadb-shard-2b) indeholder det data fra 500000 op til 999999 som forventet:

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

Mens for MariaDB Gateway-server (mariadb-gw-1 eller mariadb-gw-2), kan vi se alle rækker svarende til hvis tabellen findes inde i denne MariaDB-instans:

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

For at teste på det høje tilgængelighedsaspekt, når en shard master ikke er tilgængelig, for eksempel når masteren (mariadb-shard-2a) af shard 2 går ned, vil ClusterControl automatisk udføre slavepromoveringen på slaven (mariadb-shard-2b) at være en herre. I løbet af denne periode kunne du sandsynligvis se denne fejl:

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

Og mens den ikke er tilgængelig, vil du få følgende efterfølgende fejl:

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

I vores måling tog failover omkring 23 sekunder efter failover var påbegyndt, og når den nye master er forfremmet, skulle du være i stand til at skrive ind i tabellen fra gateway-serveren som normalt.

Konklusion

Ovenstående opsætning er et bevis på princippet om, hvordan ClusterControl kan bruges til at implementere en MariaDB sharded opsætning. Det kan også forbedre servicetilgængeligheden af ​​en MariaDB-sharding-opsætning med dens automatiske node- og klyngendannelsesfunktion plus alle industristandardstyrings- og overvågningsfunktioner til at understøtte din overordnede databaseinfrastruktur.


  1. Sådan får du århundredet fra en date i Oracle

  2. MySQL - Hvordan SUMMER man tider?

  3. Sådan omdøbes en tabelkolonne i Oracle 10g

  4. Sådan installeres PostgreSQL 12 på Ubuntu 20.04/18.04/16.04