Изпълнение на MariaDB Galera клъстер без инструменти за оркестриране на контейнери:Част първа

Инструментите за оркестриране на контейнери опростяват работата на разпределена система, като разгръщат и преразпределят контейнери и обработват всички възникнали повреди. Може да се наложи да преместите приложенията, например, за да обработвате актуализации, мащабиране или основни грешки на хоста. Въпреки че това звучи страхотно, не винаги работи добре със силно последователен клъстер от база данни като Galera. Не можете просто да местите възли на базата данни, те не са приложения без състояние. Също така редът, в който изпълнявате операциите върху клъстер, има голямо значение. Например, рестартирането на клъстер Galera трябва да започне от най-напредналия възел, в противен случай ще загубите данни. Ето защо ще ви покажем как да стартирате Galera Cluster на Docker без инструмент за оркестриране на контейнери, така че да имате пълен контрол.

В тази публикация в блога ще разгледаме как да стартираме MariaDB Galera Cluster на Docker контейнери, използвайки стандартното изображение на Docker на множество хостове на Docker, без помощта на инструменти за оркестрация като Swarm или Kubernetes. Този подход е подобен на стартирането на Galera Cluster на стандартни хостове, но управлението на процесите се конфигурира чрез Docker.

Преди да преминем по-подробно, предполагаме, че сте инсталирали Docker, деактивирали SElinux/AppArmor и сте изчистили правилата в iptables, firewalld или ufw (което и да използвате). Следват три специализирани хоста на Docker за нашия клъстер от база данни:

• host1.local - 192.168.55.161
• host2.local - 192.168.55.162
• host3.local - 192.168.55.163

Мрежа с множество хостове

На първо място, мрежата на Docker по подразбиране е свързана с локалния хост. Docker Swarm въвежда друг мрежов слой, наречен overlay network, който разширява мрежата на контейнера до множество хостове на Docker в клъстер, наречен Swarm. Много преди тази интеграция да се появи, имаше много мрежови плъгини, разработени в подкрепа на това – Flannel, Calico, Weave са някои от тях.

Тук ще използваме Weave като мрежов плъгин на Docker за работа в мрежа с множество хостове. Това се дължи главно на неговата простота за инсталиране и стартиране и поддръжка на DNS преобразувател (контейнерите, работещи под тази мрежа, могат да разрешават взаимно името на хоста). Има два начина да стартирате Weave - systemd или чрез Docker. Ще го инсталираме като systemd единица, така че да е независима от демона на Docker (в противен случай ще трябва първо да стартираме Docker, преди Weave да се активира).

1. Изтеглете и инсталирайте Weave:

   $ curl -L git.io/weave -o /usr/local/bin/weave
   $ chmod a+x /usr/local/bin/weave

2. Създайте файл systemd за Weave:

   $ cat > /etc/systemd/system/weave.service << EOF
   [Unit]
   Description=Weave Network
   Documentation=http://docs.weave.works/weave/latest_release/
   Requires=docker.service
   After=docker.service
   [Service]
   EnvironmentFile=-/etc/sysconfig/weave
   ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS
   ExecStart=/usr/bin/docker attach weave
   ExecStop=/usr/local/bin/weave stop
   [Install]
   WantedBy=multi-user.target
   EOF

3. Дефинирайте IP адреси или име на хост на партньорите в /etc/sysconfig/weave:

   $ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave

4. Стартирайте и активирайте Weave при зареждане:

   $ systemctl start weave
   $ systemctl enable weave

Повторете горните 4 стъпки на всички хостове на Docker. След като направите това, проверете със следната команда:

$ weave status

Броят на връстниците е това, за което се грижим. Трябва да е 3:

          ...
          Peers: 3 (with 6 established connections)
          ...

Изпълнение на клъстер Galera

Сега мрежата е готова, време е да задействаме нашите контейнери за база данни и да формираме клъстер. Основните правила са:

• Контейнерът трябва да бъде създаден под --net=weave, за да има свързаност с няколко хоста.
• Пристанищата на контейнера, които трябва да бъдат публикувани, са 3306, 4444, 4567, 4568.
• Изображението на Docker трябва да поддържа Galera. Ако искате да използвате Oracle MySQL, вземете версията на Codership. Ако искате Percona's, използвайте това изображение вместо това. В тази публикация в блога използваме MariaDB.

Причините, поради които избрахме MariaDB като доставчик на клъстер на Galera, са:

• Galera е вградена в MariaDB, започвайки от MariaDB 10.1.
• Образът на MariaDB се поддържа от екипите на Docker и MariaDB.
• Едно от най-популярните изображения на Docker.

Зареждането на клъстер Galera трябва да се извърши последователно. Първо, най-актуалният възел трябва да се стартира с "wsrep_cluster_address=gcomm://". След това стартирайте останалите възли с пълен адрес, състоящ се от всички възли в клъстера, например "wsrep_cluster_address=gcomm://node1,node2,node3". За да изпълним тези стъпки с помощта на контейнер, трябва да направим някои допълнителни стъпки, за да гарантираме, че всички контейнери работят хомогенно. Така че планът е:

1. Трябва да започнем с 4 контейнера в този ред – mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
2. Контейнерът mariadb0 ще използва същия datadir и configdir с mariadb1.
3. Използвайте mariadb0 на хост1 за първото стартиране, след това стартирайте mariadb2 на хост2, mariadb3 на хост3.
4. Премахнете mariadb0 на хост1, за да отстъпите място на mariadb1.
5. Накрая, стартирайте mariadb1 на хост1.

В края на деня ще имате клъстер Galera с три възела (mariadb1, mariadb2, mariadb3). Първият контейнер (mariadb0) е преходен контейнер само за целите на стартиране, използващ адрес на клъстер "gcomm://". Той споделя един и същ datadir и configdir с mariadb1 и ще бъде премахнат, след като клъстерът бъде формиран (mariadb2 и mariadb3 са готови) и възлите се синхронизират.

По подразбиране Galera е изключена в MariaDB и трябва да бъде активирана с флаг, наречен wsrep_on (включено) и wsrep_provider (настроен на пътя към библиотеката на Galera) плюс редица параметри, свързани с Galera. По този начин трябва да дефинираме персонализиран конфигурационен файл за контейнера, за да конфигурира Galera правилно.

Нека започнем с първия контейнер, mariadb0. Създайте файл под /containers/mariadb1/conf.d/my.cnf и добавете следните редове:

$ mkdir -p /containers/mariadb1/conf.d
$ cat /containers/mariadb1/conf.d/my.cnf
[mysqld]

default_storage_engine          = InnoDB
binlog_format                   = ROW

innodb_flush_log_at_trx_commit  = 0
innodb_flush_method             = O_DIRECT
innodb_file_per_table           = 1
innodb_autoinc_lock_mode        = 2
innodb_lock_schedule_algorithm  = FCFS # MariaDB >10.1.19 and >10.2.3 only

wsrep_on                        = ON
wsrep_provider                  = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method                = xtrabackup-v2

Тъй като изображението не идва с MariaDB Backup (който е предпочитаният SST метод за MariaDB 10.1 и MariaDB 10.2), за момента ще се придържаме към xtrabackup-v2.

За да извършите първото стартиране за клъстера, стартирайте контейнера за стартиране (mariadb0) на хост1 с "datadir" и "conf.d" на mariadb1:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --env MYSQL_USER=proxysql \
        --env MYSQL_PASSWORD=proxysqlpassword \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Параметрите, използвани в горната команда, са:

• --име , създава контейнера с име "mariadb0",
• --име на хост , присвоява на контейнера име на хост "mariadb0.weave.local",
• --net , поставя контейнера в мрежата за плетене за поддръжка на множество хостове,
• --публикуване , разкрива портове 3306, 4444, 4567, 4568 на контейнера на хоста,
• $(weave dns-args) , конфигурира DNS резолвер за този контейнер. Тази команда може да бъде преведена в Docker, изпълняван като "--dns=172.17.0.1 --dns-search=weave.local.",
• --env MYSQL_ROOT_PASSWORD , паролата за root на MySQL,
• --env MYSQL_USER , създава потребител "proxysql", който да се използва по-късно с ProxySQL за маршрутизиране на база данни,
• --env MYSQL_PASSWORD , потребителската парола "proxysql",
• --volume /containers/mariadb1/datadir:/var/lib/mysql , създава /containers/mariadb1/datadir, ако не съществува и го съпоставя с /var/lib/mysql (MySQL datadir) на контейнера (за възел за стартиране това може да бъде пропуснато),
• --обем /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , монтира файловете в директорията /containers/mariadb1/conf.d на хоста на Docker, в контейнера в /etc/mysql/mariadb.conf.d.
• mariadb:10.2.15 , използва изображение на MariaDB 10.2.15 от тук,
• --wsrep_cluster_address , низ за свързване на Galera за клъстера. "gcomm://" означава зареждане. За останалите контейнери вместо това ще използваме пълен адрес.
• --wsrep_sst_auth , низ за удостоверяване за SST потребител. Използвайте същия потребител като root,
• --wsrep_node_address , името на хоста на възела, в този случай ще използваме FQDN, предоставено от Weave.

Bootstrap контейнерът съдържа няколко ключови неща:

• Името, името на хоста и адреса на wsrep_node_ je mariadb0, но използва томовете на mariadb1.
• Адресът на клъстера е „gcomm://“
• Има два допълнителни параметъра --env – MYSQL_USER и MYSQL_PASSWORD. Тези параметри ще създадат допълнителен потребител за целите ни за наблюдение на proxysql.

Проверете със следната команда:

$ docker ps
$ docker logs -f mariadb0

След като видите следния ред, той показва, че процесът на стартиране е завършен и Galera е активна:

2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections

Създайте директорията, за да заредите нашия персонализиран конфигурационен файл в останалите хостове:

$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3

След това копирайте my.cnf, който създадохме за mariadb0 и mariadb1 съответно в mariadb2 и mariadb3:

$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # on host1
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3/conf.d/ # on host1

След това създайте още 2 контейнера на база данни (mariadb2 и mariadb3) съответно на host2 и host3:

$ docker run -d \
        --name ${NAME} \
        --hostname ${NAME}.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/${NAME}/datadir:/var/lib/mysql \
        --volume /containers/${NAME}/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=${NAME}.weave.local

** Заменете ${NAME} съответно с mariadb2 или mariadb3.

Има обаче уловка. Скриптът на входната точка проверява услугата mysqld във фонов режим след инициализация на базата данни, като използва root потребител на MySQL без парола. Тъй като Galera автоматично извършва синхронизация чрез SST или IST при стартиране, паролата на root на MySQL ще се промени, отразявайки стартирания възел. По този начин ще видите следната грешка по време на първото стартиране:

018-05-30 23:27:13 140003794790144 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
MySQL init process in progress…
MySQL init process failed.

Номерът е да рестартирате неуспешните контейнери още веднъж, защото този път би трябвало да бъде създаден MySQL datadir (при първия опит за стартиране) и ще пропусне частта за инициализация на базата данни:

$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3

След като започнете, проверете, като погледнете следния ред:

$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connections

В този момент работят 3 контейнера, mariadb0, mariadb2 и mariadb3. Обърнете внимание, че mariadb0 се стартира с помощта на командата bootstrap (gcomm://), което означава, че ако контейнерът бъде автоматично рестартиран от Docker в бъдеще, той потенциално може да се раздели с основния компонент. По този начин трябва да премахнем този контейнер и да го заменим с mariadb1, като използваме същия низ за връзка на Galera с останалите и използваме същия datadir и configdir с mariadb0.

Първо, спрете mariadb0, като изпратите SIGTERM (за да сте сигурни, че възелът ще бъде изключен грациозно):

$ docker kill -s 15 mariadb0

След това стартирайте mariadb1 на хост1, като използвате подобна команда като mariadb2 или mariadb3:

$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Този път не е необходимо да правите трика за рестартиране, защото MySQL datadir вече съществува (създаден от mariadb0). След като контейнерът се стартира, проверете, че размерът на клъстера е 3, състоянието трябва да е в Основен и локалното състояние е синхронизирано:

$ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'select variable_name, variable_value from information_schema.global_status where variable_name in ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'
+---------------------------+-------------------------------------------------------------------------------+
| variable_name             | variable_value                                                                |
+---------------------------+-------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 3                                                                             |
| WSREP_CLUSTER_STATUS      | Primary                                                                       |
| WSREP_INCOMING_ADDRESSES  | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

В този момент нашата архитектура изглежда така:

Въпреки че командата run е доста дълга, тя добре описва характеристиките на контейнера. Вероятно е добра идея да обвиете командата в скрипт, за да опростите стъпките за изпълнение, или вместо това да използвате файл за композиране.

Маршрутизиране на база данни с ProxySQL

Сега имаме три работещи контейнера за бази данни. Единственият начин за достъп до клъстера сега е достъп до публикувания порт на MySQL на отделния хост на Docker, който е 3306 (съпоставяне с 3306 към контейнера). И така, какво се случва, ако един от контейнерите на базата данни се провали? Трябва ръчно да преминете при отказ на връзката на клиента със следващия наличен възел. В зависимост от конектора на приложението, можете също да посочите списък с възли и да оставите конектора да извърши отказоустойчивостта и маршрутизирането на заявки вместо вас (Connector/J, PHP mysqlnd). В противен случай би било добра идея ресурсите на базата данни да се обединят в един ресурс, който може да се нарече услуга.

Тук се появява ProxySQL. ProxySQL може да действа като рутер за заявки, като балансира натоварването на връзките към базата данни, подобно на това, което може да направи "Услугата" в света на Swarm или Kubernetes. Създадохме изображение на ProxySQL Docker за тази цел и ще поддържаме изображението за всяка нова версия с най-доброто от нас.

Преди да стартираме контейнера ProxySQL, трябва да подготвим конфигурационния файл. Следва това, което сме конфигурирали за proxysql1. Създаваме персонализиран конфигурационен файл под /containers/proxysql1/proxysql.cnf на хост1:

$ cat /containers/proxysql1/proxysql.cnf
datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassword"
}
mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "sbtest" , password = "password" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
scheduler =
(
        {
                id = 1
                filename = "/usr/share/proxysql/tools/proxysql_galera_checker.sh"
                active = 1
                interval_ms = 2000
                arg1 = "10"
                arg2 = "20"
                arg3 = "1"
                arg4 = "1"
                arg5 = "/var/lib/proxysql/proxysql_galera_checker.log"
        }
)

Горната конфигурация ще:

• конфигурирайте две хост групи, групата с единичен запис и групата за записване, както е дефинирано в раздела „mysql_servers“,
• изпратете прочитания до всички възли на Galera (хостгрупа 20), докато операциите по запис ще отидат до един сървър на Galera (хостгрупа 10),
• насрочете proxysql_galera_checker.sh,
• използвайте monitor_username и monitor_password като идентификационни данни за наблюдение, създадени, когато за първи път стартирахме клъстера (mariadb0).

Копирайте конфигурационния файл на host2, за резервиране на ProxySQL:

$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1

След това стартирайте ProxySQL контейнерите съответно на хост1 и хост2:

$ docker run -d \
        --name=${NAME} \
        --publish 6033 \
        --publish 6032 \
        --restart always \
        --net=weave \
        $(weave dns-args) \
        --hostname ${NAME}.weave.local \
        -v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \
        -v /containers/${NAME}/data:/var/lib/proxysql \
        severalnines/proxysql

** Заменете ${NAME} съответно с proxysql1 или proxysql2.

Ние посочихме --restart=always за да го направи винаги достъпен, независимо от състоянието на изход, както и автоматично стартиране при стартиране на демона на Docker. Това ще гарантира, че ProxySQL контейнерите действат като демон.

Проверете състоянието на MySQL сървърите, наблюдавано от двата екземпляра на ProxySQL (очаква се OFFLINE_SOFT за хост групата с един запис):

$ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'select hostgroup_id,hostname,status from mysql_servers'
+--------------+----------------------+--------------+
| hostgroup_id | hostname             | status       |
+--------------+----------------------+--------------+
| 10           | mariadb1.weave.local | ONLINE       |
| 10           | mariadb2.weave.local | OFFLINE_SOFT |
| 10           | mariadb3.weave.local | OFFLINE_SOFT |
| 20           | mariadb1.weave.local | ONLINE       |
| 20           | mariadb2.weave.local | ONLINE       |
| 20           | mariadb3.weave.local | ONLINE       |
+--------------+----------------------+--------------+

В този момент нашата архитектура изглежда така:

Всички връзки, идващи от 6033 (от хост1, хост2 или мрежата на контейнера) ще бъдат балансирани на натоварването към контейнерите на задната база данни с помощта на ProxySQL. Ако искате да получите достъп до отделен сървър на база данни, използвайте вместо това порт 3306 на физическия хост. Няма виртуален IP адрес като единична крайна точка, конфигурирана за услугата ProxySQL, но бихме могли да го имаме, като използваме Keepalived, което е обяснено в следващия раздел.

Виртуален IP адрес с Keepalived

Тъй като конфигурирахме ProxySQL контейнерите да се изпълняват на хост1 и хост2, ще използваме контейнери Keepalived, за да свържем тези хостове заедно и да предоставим виртуален IP адрес чрез хост мрежата. Това позволява на една крайна точка за приложения или клиенти да се свързват към слоя за балансиране на натоварването, подкрепен от ProxySQL.

Както обикновено, създайте персонализиран конфигурационен файл за нашата услуга Keepalived. Ето съдържанието на /containers/keepalived1/keepalived.conf:

vrrp_instance VI_DOCKER {
   interface ens33               # interface to monitor
   state MASTER
   virtual_router_id 52          # Assign one ID for this route
   priority 101
   unicast_src_ip 192.168.55.161
   unicast_peer {
      192.168.55.162
   }
   virtual_ipaddress {
      192.168.55.160             # the virtual IP
}

Копирайте конфигурационния файл на host2 за втория екземпляр:

$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1

Променете приоритета от 101 на 100 вътре в копирания конфигурационен файл на хост2:

$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf

**Екземплярът с по-висок приоритет ще задържи виртуалния IP адрес (в този случай е хост1), докато VRRP комуникацията не бъде прекъсната (в случай, че хост1 изпадне).

След това изпълнете следната команда съответно на хост1 и хост2:

$ docker run -d \
        --name=${NAME} \
        --cap-add=NET_ADMIN \
        --net=host \
        --restart=always \
        --volume /containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4

** Заменете ${NAME} с keepalived1 и keepalived2.

Командата run казва на Docker да:

• --име , създайте контейнер с
• --cap-add=NET_ADMIN , добавете възможности на Linux за обхват на мрежов администратор
• --net=host , прикачете контейнера към хост мрежата. Това ще осигури виртуален IP адрес на интерфейса на хоста, ens33
• --restart=always , винаги поддържайте контейнера работещ,
• --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , съпоставете персонализирания конфигурационен файл за използване на контейнера.

След като и двата контейнера са стартирани, проверете съществуването на виртуален IP адрес, като погледнете физическия мрежов интерфейс на MASTER възела:

$ ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33
    inet 192.168.55.160/32 scope global ens33

Клиентите и приложенията вече могат да използват виртуалния IP адрес 192.168.55.160 за достъп до услугата за база данни. Този виртуален IP адрес съществува на хост1 в момента. Ако host1 падне, keepalived2 ще поеме IP адреса и ще го изведе на хост2. Обърнете внимание, че конфигурацията за този keepalived не наблюдава ProxySQL контейнерите. Той наблюдава само VRRP рекламата на пиърите Keepalived.

В този момент нашата архитектура изглежда така:

Резюме

И така, сега имаме MariaDB Galera Cluster, предстван от високодостъпна ProxySQL услуга, всички работещи на Docker контейнери.

В част втора ще разгледаме как да управляваме тази настройка. Ще разгледаме как да извършваме операции като грациозно изключване, стартиране, откриване на най-усъвършенствания възел, отказ, възстановяване, мащабиране нагоре/намаляване, надстройки, архивиране и така нататък. Ще обсъдим също плюсовете и минусите на тази настройка за нашата услуга за клъстерна база данни.

Приятно контейнеризиране!