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

Distribuzione di MariaDB Sharding con Spider utilizzando ClusterControl

MariaDB offre funzionalità di sharding multi-host integrate con il motore di archiviazione Spider. Spider supporta il partizionamento e le transazioni XA e consente di gestire le tabelle remote di diverse istanze MariaDB come se si trovassero sulla stessa istanza. La tabella remota può essere di qualsiasi motore di archiviazione. Il collegamento delle tabelle si ottiene stabilendo la connessione da un server MariaDB locale a un server MariaDB remoto e il collegamento è condiviso per tutte le tabelle che fanno parte della stessa transazione.

In questo post del blog, ti guideremo attraverso la distribuzione di un cluster di due shard MariaDB utilizzando ClusterControl. Distribuiremo una manciata di server MariaDB (per ridondanza e disponibilità) per ospitare una tabella partizionata in base a un intervallo di una chiave shard selezionata. La chiave shard scelta è fondamentalmente una colonna che memorizza valori con un limite inferiore e superiore, come in questo caso, valori interi compresi tra 0 e 1.000.000, rendendola la migliore chiave candidata per bilanciare la distribuzione dei dati tra due shard. Pertanto, divideremo gli intervalli in due partizioni:

  • 0 - 499999:Frammento 1

  • 500000 - 1000000:Shard 2

Il diagramma seguente illustra la nostra architettura di alto livello di ciò che andremo a distribuire:

Alcune spiegazioni del diagramma:

  1. mariadb-gw-1:l'istanza MariaDB che esegue il motore di archiviazione Spider, si comporta come un router shard. Diamo un nome a questo host come MariaDB Gateway 1 e questo sarà il server MariaDB principale (attivo) per raggiungere gli shard. L'applicazione si connetterà a questo host come una connessione MariaDB standard. Questo nodo si connette agli shard tramite HAProxy in ascolto sulle porte 127.0.0.1 3307 (shard1) e 3308 (shard2).

  2. mariadb-gw-2:l'istanza MariaDB che esegue il motore di archiviazione Spider, si comporta come un router shard. Diamo un nome a questo host come MariaDB Gateway 2 e questo sarà il server MariaDB secondario (passivo) per raggiungere gli shard. Avrà la stessa configurazione di mariadb-gw-1. L'applicazione si connetterà a questo host solo se il MariaDB primario è inattivo. Questo nodo si connette agli shard tramite HAProxy in ascolto sulle porte 127.0.0.1 3307 (shard1) e 3308 (shard2).

  3. mariadb-shard-1a:master MariaDB che funge da nodo dati primario per la prima partizione. I server gateway MariaDB devono scrivere solo sul master dello shard.

  4. mariadb-shard-1b:replica MariaDB che funge da nodo dati secondario per la prima partizione. Assume il ruolo di master nel caso in cui il master dello shard si interrompa (il failover automatico è gestito da ClusterControl).

  5. mariadb-shard-2a:master MariaDB che funge da nodo dati primario per la seconda partizione. I server gateway MariaDB scrivono solo sul master dello shard.

  6. mariadb-shard-2b:replica MariaDB che funge da nodo dati secondario per la seconda partizione. Assume il ruolo di master nel caso in cui il master dello shard si interrompa (il failover automatico è gestito da ClusterControl).

  7. ClusterControl:uno strumento centralizzato di distribuzione, gestione e monitoraggio per i nostri shard/cluster MariaDB.

Distribuzione di cluster di database utilizzando ClusterControl

ClusterControl è uno strumento di automazione per gestire il ciclo di vita del tuo sistema di gestione di database open source. Utilizzeremo ClusterControl come strumento centralizzato per distribuzioni di cluster, gestione della topologia e monitoraggio ai fini di questo post sul blog.

1) Installare ClusterControl.

2) Configurare l'SSH senza password dal server ClusterControl a tutti i nodi del database. Sul nodo 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) Poiché implementeremo 4 set di cluster, è una buona idea utilizzare lo strumento ClusterControl CLI per questa particolare attività per accelerare e semplificare il processo di distribuzione. Verifichiamo prima di tutto se possiamo connetterci con le credenziali predefinite eseguendo il comando seguente (la credenziale predefinita è configurata automaticamente in /etc/s9s.conf):

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

Se non riceviamo errori e vediamo un output simile a quello sopra, siamo a posto.

4) Si noti che i passaggi 4,5,6 e 7 possono essere eseguiti contemporaneamente poiché ClusterControl supporta la distribuzione parallela. Inizieremo distribuendo il primo server MariaDB Gateway utilizzando 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) Distribuire il secondo 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) Distribuisci una replica MariaDB a 2 nodi per il primo 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) Distribuire una replica MariaDB a 2 nodi per il secondo 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"

Mentre la distribuzione è in corso, possiamo monitorare l'output del lavoro dalla 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

E anche dall'interfaccia utente di ClusterControl:

Una volta completata la distribuzione, dovresti vedere qualcosa che i cluster di database sono elencati in questo modo nella dashboard ClusterControl:

I nostri cluster sono ora distribuiti ed eseguono l'ultima versione di MariaDB 10.5. Successivamente, è necessario configurare HAProxy per fornire un singolo endpoint agli shard MariaDB.

Configura HAProxy

HAProxy è necessario come singolo endpoint per la replica master-slave dello shard. Altrimenti, se un master si interrompe, è necessario aggiornare l'elenco dei server di Spider utilizzando l'istruzione CREATE OR REPLACE SERVER nei server gateway, eseguire ALTER TABLE e passare un nuovo parametro di connessione. Con HAProxy, possiamo configurarlo per essere in ascolto sull'host locale del server gateway e monitorare diversi shard MariaDB con porte diverse. Configurare HAProxy su entrambi i server gateway come segue:

  • 127.0.0.1:3307 -> Shard1 (i server di backend sono mariadb-shard-1a e mariadb-shard- 1b)

  • 127.0.0.1:3308 -> Shard2 (i server di backend sono mariadb-shard-2a e mariadb-shard- 2b)

In caso di guasto del master dello shard, ClusterControl eseguirà il failover dello slave dello shard come nuovo master e HAProxy reindirizzerà le connessioni al nuovo master di conseguenza. Installeremo HAProxy sui server gateway (mariadb-gw-1 e mariadb-gw-2) utilizzando ClusterControl poiché configurerà automaticamente i server back-end (configurazione mysqlchk, autorizzazioni utente, installazione xinetd) con alcuni trucchi come mostrato di seguito.

Prima di tutto, sulla ClusterControl UI, scegli il primo shard, MariaDB - Shard 1 -> Manage -> Load Balancer -> HAProxy -> Deploy HAProxy e specifica l'indirizzo del server come 192.168.22.101 ( mariadb-gw-1), simile allo screenshot seguente:

Allo stesso modo, ma questo per lo shard 2, vai su MariaDB - Shard 2 -> Gestisci -> Load Balancer -> HAProxy -> Distribuisci HAProxy e specifica l'indirizzo del server come 192.168.22.102 (mariadb-gw-2). Attendi fino al termine della distribuzione per entrambi i nodi HAProxy.

Ora è necessario configurare il servizio HAProxy su mariadb-gw-1 e mariadb-gw-2 per bilanciare il carico di tutti gli shard contemporaneamente. Utilizzando l'editor di testo (o ClusterControl UI -> Gestisci -> Configurazioni), modifica le ultime 2 direttive "ascolta" di /etc/haproxy/haproxy.cfg in modo che assomiglino a questa:

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

Riavvia il servizio HAProxy per caricare le modifiche (o usa ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

Dall'interfaccia utente di ClusterControl, possiamo verificare che sia attivo un solo server backend per shard (indicato dalle linee verdi), come mostrato di seguito:

A questo punto, la distribuzione del nostro cluster di database è ora completa. Possiamo procedere alla configurazione dello sharding di MariaDB utilizzando il motore di archiviazione Spider.

Preparazione dei server gateway MariaDB

Su entrambi i server MariaDB Gateway (mariadb-gw-1 e mariadb-gw-2), eseguire le seguenti attività:

Installa il plug-in Spider:

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

Verifica se il motore di archiviazione è supportato:

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

Opzionalmente, possiamo anche verificare se il plugin è stato caricato correttamente dal database 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 |
+--------------------------+----------------+---------------+--------------------+

Aggiungi la seguente riga nella sezione [mysqld] all'interno del file di configurazione di MariaDB:

plugin-load-add = ha_spider

Crea il primo "nodo di dati" per il primo shard che dovrebbe essere accessibile tramite HAProxy 127.0.0.1 sulla porta 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);

Crea il secondo "nodo di dati" per il secondo shard che dovrebbe essere accessibile tramite HAProxy 127.0.0.1 sulla porta 3308:

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

Ora possiamo creare una tabella Spider che deve essere partizionata. In questo esempio, creeremo una tabella chiamata sbtest1 all'interno del database sbtest e partizionata per il valore intero nella colonna '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"'
);

Si noti che le clausole COMMENT ='srv "ShardX"' dell'istruzione CREATE TABLE sono critiche, in cui trasmettiamo le informazioni di connessione sul server remoto. Il valore deve essere identico al nome del server come nell'istruzione CREATE SERVER. Riempiremo questa tabella usando il generatore di carico Sysbench come mostrato più avanti.

Creare l'utente del database dell'applicazione per accedere al database e consentirlo dai server delle applicazioni:

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

In questo esempio, poiché si tratta di una rete interna affidabile, utilizziamo semplicemente un carattere jolly nell'istruzione per consentire qualsiasi indirizzo IP nello stesso intervallo, 192.168.22.0/24.

Siamo ora pronti per configurare i nostri nodi di dati.

Preparazione dei server shard MariaDB

Su entrambi i server master MariaDB Shard (mariadb-shard-1a e mariadb-shard-2a), eseguire le seguenti attività:

1) Crea il database di destinazione:

MariaDB> CREATE SCHEMA sbtest;

2) Creare l'utente 'spider' e consentire le connessioni dai server gateway (mariadb-gw-1 e mariadb-gw2). Questo utente deve avere tutti i privilegi sulla tabella partizionata e anche sul database di sistema 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.%';

In questo esempio, poiché si tratta di una rete interna affidabile, utilizziamo semplicemente un carattere jolly nell'istruzione per consentire qualsiasi indirizzo IP nello stesso intervallo, 192.168.22.0/24.

3) Creare la tabella che riceverà i dati dai nostri server gateway tramite il motore di archiviazione Spider. Questa tabella "ricevitore" può trovarsi su qualsiasi motore di archiviazione supportato da MariaDB. In questo esempio, utilizziamo il motore di archiviazione 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;

Ecco fatto. Non dimenticare di ripetere i passaggi sull'altro shard.

Test

Per testare l'utilizzo di Sysbench per generare alcuni carichi di lavoro del database, sul server delle applicazioni, dobbiamo prima installare Sysbench:

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

Genera alcuni carichi di lavoro di prova e inviali al primo server gateway, 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

Puoi ripetere il test precedente su mariadb-gw-2 (192.168.11.102) e le connessioni al database dovrebbero essere indirizzate allo shard corretto di conseguenza.

Guardando il primo shard (mariadb-shard-1a o mariadb-shard-1b), possiamo dire che questa partizione contiene solo righe in cui la chiave shard (colonna k) è inferiore a 500000:

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

Su un altro shard (mariadb-shard-2a o mariadb-shard-2b), contiene dati da 500000 fino a 999999 come previsto:

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

Mentre per il server MariaDB Gateway (mariadb-gw-1 o mariadb-gw-2), possiamo vedere tutte le righe simili a se la tabella esistesse all'interno di questa istanza MariaDB:

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

Per testare l'aspetto dell'alta disponibilità, quando uno shard master non è disponibile, ad esempio quando il master (mariadb-shard-2a) dello shard 2 va inattivo, ClusterControl eseguirà automaticamente la promozione slave su lo schiavo (mariadb-shard-2b) per essere un padrone. Durante questo periodo, potresti probabilmente visualizzare questo errore:

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

E sebbene non sia disponibile, riceverai il seguente errore successivo:

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

Nella nostra misurazione, il failover ha impiegato circa 23 secondi dopo l'inizio del failover e una volta promosso il nuovo master, dovresti essere in grado di scrivere nella tabella dal server gateway come al solito.

Conclusione

La configurazione di cui sopra è una prova di principio su come ClusterControl può essere utilizzato per distribuire una configurazione sharded MariaDB. Può anche migliorare la disponibilità del servizio di una configurazione di sharding MariaDB con la sua funzione di ripristino automatico di nodi e cluster, oltre a tutte le funzionalità di gestione e monitoraggio standard del settore per supportare l'intera infrastruttura del database.