MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Разгръщане на MariaDB Sharding с Spider с помощта на ClusterControl

MariaDB предлага вградени възможности за разделяне на множество хостове с механизма за съхранение на Spider. Spider поддържа разделяне и XA транзакции и позволява да се обработват отдалечени таблици на различни екземпляри на MariaDB, сякаш са в един и същи екземпляр. Отдалечената маса може да бъде с всякакъв механизъм за съхранение. Свързването на таблицата се постига чрез установяване на връзката от локален сървър на MariaDB към отдалечен сървър на MariaDB и връзката се споделя за всички таблици, които са част от една и съща транзакция.

В тази публикация в блога ще ви преведем през внедряването на клъстер от два MariaDB шарда, използвайки ClusterControl. Ще разположим шепа сървъри на MariaDB (за резервиране и наличност), за да хостваме разделена таблица на базата на диапазон от избран ключ за сегменти. Избраният ключ за фрагмент е основно колона, която съхранява стойности с долна и горна граница, както в този случай, целочислени стойности между 0 до 1 000 000, което го прави най-добрият кандидат ключ за балансиране на разпределението на данни между два сегмента. Следователно, ние ще разделим диапазоните на два дяла:

  • 0 - 499999:Shard 1

  • 500000 - 1000000:Shard 2

Следната диаграма илюстрира нашата архитектура на високо ниво на това, което ще внедрим:

Някои обяснения на диаграмата:

  1. mariadb-gw-1:екземпляр на MariaDB, който изпълнява механизма за съхранение на Spider, действа като рутер за фрагменти. Даваме име на този хост като MariaDB Gateway 1 и това ще бъде основният (активен) MariaDB сървър за достигане до шардовете. Приложението ще се свърже с този хост като стандартна връзка с MariaDB. Този възел се свързва с шардовете чрез HAProxy слушане на 127.0.0.1 портове 3307 (шард1) и 3308 (шард2).

  2. mariadb-gw-2:екземпляр на MariaDB, който изпълнява механизма за съхранение на Spider, действа като рутер за фрагменти. Даваме име на този хост като MariaDB Gateway 2 и това ще бъде вторичният (пасивен) сървър на MariaDB, за да достигне до фрагментите. Той ще има същата настройка като mariadb-gw-1. Приложението ще се свърже с този хост само ако основният MariaDB не работи. Този възел се свързва с шардовете чрез HAProxy слушане на 127.0.0.1 портове 3307 (шард1) и 3308 (шард2).

  3. mariadb-shard-1a:MariaDB master, който служи като основен възел за данни за първия дял. Сървърите на шлюзовете на MariaDB трябва да пишат само до главната част на шарда.

  4. mariadb-shard-1b:MariaDB реплика, която служи като вторичен възел за данни за първия дял. Той ще поеме главната роля в случай, че главната част на шарда изпадне (автоматичното преминаване при отказ се управлява от ClusterControl).

  5. mariadb-shard-2a:MariaDB master, който служи като основен възел за данни за втория дял. Сървърите на шлюзовете на MariaDB пишат само до главната част на шарда.

  6. mariadb-shard-2b:MariaDB реплика, която служи като вторичен възел за данни за втория дял. Той ще поеме главната роля в случай, че главната част на шарда изпадне (автоматичното преминаване при отказ се управлява от ClusterControl).

  7. ClusterControl:централизиран инструмент за разгръщане, управление и наблюдение за нашите MariaDB фрагменти/клъстери.

Разгръщане на клъстери от база данни с помощта на ClusterControl

ClusterControl е инструмент за автоматизация за управление на жизнения цикъл на вашата система за управление на база данни с отворен код. Ще използваме ClusterControl като централизиран инструмент за внедряване на клъстери, управление на топологията и наблюдение за целите на тази публикация в блога.

1) Инсталирайте ClusterControl.

2) Конфигурирайте SSH без парола от сървъра на ClusterControl към всички възли на базата данни. На възела 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) Тъй като ще внедрим 4 комплекта клъстери, е добра идея да използвате ClusterControl CLI инструмента за тази конкретна задача, за да ускорите и опростите процеса на внедряване. Нека първо проверим дали можем да се свържем с идентификационните данни по подразбиране, като изпълним следната команда (идентификационните данни по подразбиране се конфигурират автоматично в /etc/s9s.conf):

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

Ако не получим никакви грешки и видим подобен изход като по-горе, сме готови.

4) Имайте предвид, че стъпки 4, 5, 6 и 7 могат да бъдат изпълнени наведнъж, тъй като ClusterControl поддържа паралелно внедряване. Ще започнем с внедряването на първия MariaDB Gateway сървър с помощта на 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) Разгръщане на втория сървър на 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) Разгръщане на MariaDB репликация с 2 възела за първия шард:

(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) Разгръщане на MariaDB репликация с 2 възела за втория шард:

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

Докато внедряването е в ход, можем да наблюдаваме изхода на заданието от 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

А също и от потребителския интерфейс на ClusterControl:

След като внедряването приключи, трябва да видите нещо, което клъстерите на базата данни са изброени като това в таблото за управление на ClusterControl:

Нашите клъстери вече са внедрени и работят с най-новата версия на MariaDB 10.5. След това трябва да конфигурираме HAProxy да предостави единична крайна точка на MariaDB фрагментите.

Конфигуриране на HAProxy

HAProxy е необходим като единична крайна точка за репликацията главен-подчинен на шарда. В противен случай, ако капитана падне, човек трябва да актуализира списъка със сървъри на Spider, използвайки оператора CREATE OR REPLACE SERVER в сървърите на шлюза и да изпълни ALTER TABLE и да подаде нов параметър за връзка. С HAProxy можем да го конфигурираме да слуша на локалния хост на сървъра на шлюза и да наблюдава различни MariaDB фрагменти с различни портове. Ще конфигурираме HAProxy и на двата шлюз сървъра, както следва:

  • 127.0.0.1:3307 -> Shard1 (задните сървъри са mariadb-shard-1a и mariadb-shard- 1б)

  • 127.0.0.1:3308 -> Shard2 (задните сървъри са mariadb-shard-2a и mariadb-shard- 2б)

В случай, че главната част на шарда се повреди, ClusterControl ще превключи подчинения на шарда, тъй като новият главен и HAProxy съответно ще пренасочи връзките към новия главен. Ще инсталираме HAProxy на сървърите на шлюза (mariadb-gw-1 и mariadb-gw-2), използвайки ClusterControl, тъй като той автоматично ще конфигурира бекенд сървърите (настройка на mysqlchk, потребителски разрешения, инсталиране на xinetd) с някои трикове, както е показано по-долу.

Първо, в потребителския интерфейс на ClusterControl изберете първия фрагмент, MariaDB - Shard 1 -> Manage -> Load Balancers -> HAProxy -> Deploy HAProxy и посочете адреса на сървъра като 192.168.22.101 ( mariadb-gw-1), подобно на следната екранна снимка:

По същия начин, но този за шард 2, отидете на MariaDB - Shard 2 -> Управление -> Балансьори на натоварване -> HAProxy -> Разгръщане на HAProxy и посочете адреса на сървъра като 192.168.22.102 (mariadb-gw-2). Изчакайте, докато разполагането завърши и за двата HAProxy възела.

Сега трябва да конфигурираме услугата HAProxy на mariadb-gw-1 и mariadb-gw-2, за да балансира натоварването на всички сегменти наведнъж. Използвайки текстов редактор (или ClusterControl UI -> Manage -> Configurations), редактирайте последните 2 директиви "listen" на /etc/haproxy/haproxy.cfg, за да изглеждат така:

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

Рестартирайте услугата HAProxy, за да заредите промените (или използвайте ClusterControl -> Nodes -> HAProxy -> Restart Node):

$ systemctl restart haproxy

От потребителския интерфейс на ClusterControl можем да потвърдим, че само един бекенд сървър е активен на шард (обозначен със зелените линии), както е показано по-долу:

На този етап внедряването на клъстера ни от база данни вече е завършено. Можем да продължим да конфигурираме разделянето на MariaDB с помощта на механизма за съхранение на Spider.

Подготовка на MariaDB Gateway сървъри

И на двата сървъра на MariaDB Gateway (mariadb-gw-1 и mariadb-gw-2) изпълнете следните задачи:

Инсталиране на плъгин Spider:

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

Проверете дали машината за съхранение се поддържа:

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

По избор можем също да проверим дали плъгинът е зареден правилно от базата данни 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 |
+--------------------------+----------------+---------------+--------------------+

Добавете следния ред под секцията [mysqld] в конфигурационния файл на MariaDB:

plugin-load-add = ha_spider

Създайте първия "възел за данни" за първия шард, който трябва да бъде достъпен чрез HAProxy 127.0.0.1 на порт 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);

Създайте втория „възел за данни“ за втория шард, който трябва да бъде достъпен чрез HAProxy 127.0.0.1 на порт 3308:

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

Сега можем да създадем таблица Spider, която трябва да бъде разделена. В този пример ще създадем таблица, наречена sbtest1 вътре в базата данни sbtest и разделена на целочислена стойност в колоната '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"'
);

Обърнете внимание, че клаузите COMMENT ='srv "ShardX"' на оператора CREATE TABLE са от решаващо значение, където предаваме информация за връзката за отдалечения сървър. Стойността трябва да е идентична с името на сървъра, както в оператора CREATE SERVER. Ще попълним тази таблица с помощта на генератора на натоварване на Sysbench, както е показано по-долу.

Създайте потребителя на базата данни на приложението за достъп до базата данни и го разрешете от сървърите на приложения:

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

В този пример, тъй като това е надеждна вътрешна мрежа, ние просто използваме заместващ знак в израза, за да разрешим всеки IP адрес в същия диапазон, 192.168.22.0/24.

Вече сме готови да конфигурираме нашите възли за данни.

Подготовка на MariaDB Shard сървъри

И на двата главни сървъра на MariaDB Shard (mariadb-shard-1a и mariadb-shard-2a) изпълнете следните задачи:

1) Създайте целевата база данни:

MariaDB> CREATE SCHEMA sbtest;

2) Създайте потребителя 'spider' и разрешете връзки от сървърите на шлюза (mariadb-gw-1 и mariadb-gw2). Този потребител трябва да има всички привилегии върху разчленената таблица, а също и системната база данни 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.%';

В този пример, тъй като това е надеждна вътрешна мрежа, ние просто използваме заместващ знак в израза, за да разрешим всеки IP адрес в същия диапазон, 192.168.22.0/24.

3) Създайте таблицата, която ще получава данните от нашите шлюз сървъри чрез Spider машина за съхранение. Тази таблица на "получател" може да бъде на всяка машина за съхранение, поддържана от MariaDB. В този пример използваме 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;

Това е. Не забравяйте да повторите стъпките за другия фрагмент.

Тестване

За да тестваме използването на Sysbench за генериране на някои работни натоварвания на база данни, на сървъра на приложения, трябва да инсталираме Sysbench предварително:

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

Генерирайте някои тестови натоварвания и ги изпратете до първия шлюз сървър, 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

Можете да повторите горния тест на mariadb-gw-2 (192.168.11.102) и връзките към базата данни трябва да бъдат съответно насочени към десния шард.

Когато разглеждаме първия фрагмент (mariadb-shard-1a или mariadb-shard-1b), можем да кажем, че този дял съдържа само редове, където ключът на шарда (колона k) е по-малък от 500 000:

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

В друг шард (mariadb-shard-2a или mariadb-shard-2b) той съхранява данни от 500 000 до 999999, както се очаква:

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

Докато за MariaDB Gateway сървър (mariadb-gw-1 или mariadb-gw-2), можем да видим всички редове, подобни на ако таблицата съществува в този екземпляр на MariaDB:

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

За да тествате на аспекта с висока наличност, когато главен елемент не е наличен, например когато главният (mariadb-shard-2a) на сегмент 2 изпадне, ClusterControl автоматично ще извърши повишението на подчинен елемент на робът (mariadb-shard-2b) да бъде господар. През този период вероятно бихте могли да видите тази грешка:

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

И докато не е наличен, ще получите следната последваща грешка:

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

При нашето измерване преминаването при отказ отне около 23 секунди след започване на отказ и след като новият главен елемент бъде повишен, трябва да можете да пишете в таблицата от сървъра на шлюза, както обикновено.

Заключение

Горената настройка е доказателство за принципа за това как ClusterControl може да се използва за разгръщане на разчленена настройка на MariaDB. Той също така може да подобри наличността на услугата на настройка за споделяне на MariaDB с нейната функция за автоматично възстановяване на възли и клъстери, плюс всички стандартни за индустрията функции за управление и наблюдение, за да поддържате цялостната ви инфраструктура на базата данни.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Случаи на използване на MariaDB и Docker, част 1

  2. Как работи операторът BINARY в MariaDB

  3. Как да изброите всички съхранени процедури в MariaDB

  4. Как работи EXP() в MariaDB

  5. Проучване на опциите на Storage Engine за MariaDB