Galera cluster с MariaDB

Galera Cluster является оптимальным решением для репликации MySQL. Кластер позволяет избежать задержек данных при их копировании с одной ноды на другую в отличие от традиционной Master-Slave репликации.

Galera cluster обеспечивает отказоустойчивость, при выходе из строя одной ноды приложение обслуживает другая или другие. При повторном включении информация на отсутствующей ноде синхронизируется (по-молчанию передача rsync-ом).

 

В рамках данного материала рассмотрена настройка Galera Cluster на двух нодах и Haproxy, балансирующий нагрузку между ними. Приложение запущено на четвертом сервере.

 

 

Galera cluster с MariaDB на Debian 8

На трех серверах сменим hostname указав его в соответствии с выполняемой сервером функцией:

 

  • galera1
  • galera2
  • haproxy

Все сервера объединены в локальную сеть с адресами 192.168.0.1 (galera1), 192.168.0.2 (galera2) и 192.168.0.3 (haproxy). Последний сервер также имеет белый внешний IP адрес 123.123.123.123.

Сразу разрешим пробрасывать пакеты с внешнего интерфейса на тот, что находится в локальной сети — это потребуется позже

echo «1» > /proc/sys/net/ipv4/ip_forward

 

Устанавливаем на galera1 и galera2 mariadb 10 предварительно подключив необходимые репозитории:

 

mcedit /etc/apt/sources.list.d/MariaDB.list

# MariaDB 10.2 repository list — created 2017-09-23 05:52 UTC
# http://downloads.mariadb.org/mariadb/repositories/
deb [arch=amd64,i386] http://mirror.timeweb.ru/mariadb/repo/10.2/debian jessie main
deb-src http://mirror.timeweb.ru/mariadb/repo/10.2/debian jessie main

 

apt-get update

 

Ищем доступные для установки пакеты в репозитории

apt-cache search mariadb-server

auth2db — Powerful and eye-candy IDS logger, log viewer and alert generator
mariadb-server-10.0 — MariaDB database server binaries
mariadb-server-core-10.0 — MariaDB database core server files
mariadb-server — MariaDB database server (metapackage depending on the latest version)
mariadb-server-10.2 — MariaDB database server binaries
mariadb-server-core-10.2 — MariaDB database core server files

 

Устанавиваем mariadb-server

apt-get install mariadb-server

 

Если на предыдущем этапе не был добавлен ключ к репозиторию возникнет предупреждение:

WARNING: The following packages cannot be authenticated!.

 

Можно не обращать на него внимания и дать согласие на установку пакетов без подтверждения. У процессе установки потребуется дважды ввести пароль пользователя root MySQL (MySQL употребляется в качестве синонима MariaDB)

 

root пароль mysql

Затем запрашивается повторный ввод пароля root — вводим его повторно.
Когда процесс установки завершен авторизуемся в консоли сервера баз данных.

mysql -u root -p

galera cluster

 

Далее нужно выполнить скрипт безопасной установки, который выведя несколько диалогов подготоит сервер баз данных к работе скорректируя некоторые настройки заданные по-умолчанию (ответ, который нужно давать указан в виде y и n сразу после вопроса)

 

root@galera1:~# /usr/bin/mysql_secure_installation

Enter current password for root (enter for none):
Change the root password? [Y/n] n
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] n
Remove test database and access to it? [Y/n] y
Reload privilege tables now? [Y/n] y

 

 

Вновь авторизуемся в консоли и создаем пользователя user с паролем pass, который будет использоваться на всех нодах, поскольку в качестве сервера указыаем «%» — авторизоваться от имени user можно будет с любой внешней машины и с localhost

mysql -u root -p

GRANT ALL PRIVILEGES ON *.* TO 'user'@'%' IDENTIFIED BY 'pass' WITH GRANT OPTION;

Чтобы изменения вступили в силу обновляем привелегии:

FLUSH PRIVILEGES;

exit

Также нужно настроить одинаковый пароль для системного пользователя debian-sys-maint, иначе будут возникать ошибки.

 

Теперь нужно скорректировать кофнигурационный файл сервера баз данных: (/etc/mysql/my.cnf)

Ставим знак комменария перед директивой bind_address=127.0.0.1 чтобы разрешить удаленное подключение

Далее в секцию [mysqld] добавляем следующие директивы (можно также раскомментировать те, что содержатся в конфигуационном файле по-умолчанию и относятся в galera)

query_cache_size=0
binlog_format=ROW
innodb_autoinc_lock_mode=2
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address=»gcomm://192.168.0.1,192.168.0.2,192.168.0.3"
wsrep_cluster_name='cluster1'
wsrep_node_address='192.168.0.1'
wsrep_node_name='galera-db02'
wsrep_sst_method=rsync
wsrep_sst_auth=user:pass

Для galera2 проделываем все то же, но в /etc/mysql/my.cnf  в директиве wsrep_node_address прописываем локальный адрес этой ноды — 192.168.0.2

wsrep_on=ON используется для того чтобы запустить репликацию, чтобы работать с MySQL без нее нужно каждый раз ставить знак комментиря перед опцией.

 

На обеих нодах останавливаем MySQL

/etc/init.d/mysql stop

 

Запускаем кластер на первой ноде galera1

mysqld —wsrep-new-cluster

Вторая нода вводится в процесс репликации просто путем включения

/etc/init.d/mysql start

 

При всех последующих инициализациях кластера —wsrep-new-cluster нужно запускать на сервер последним выведенным из предыдущемго процесса чтобы не было рассинхронизации.

Иначе будет выводится предупреждение:

It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

 

Как следует из его текста подавить такое повденеие galera можно добавив safe_to_bootstrap=1 в файл /var/lib/mysql/grastate.dat

Проверяем все ли получилось

 

root@galera2:~# mysql -u root -p789123 -e «show status like 'wsrep%'»

+——————————+—————————————————+
| Variable_name | Value |
+——————————+—————————————————+
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 0.000000 |
| wsrep_causal_reads | 0 |
| wsrep_cert_deps_distance | 0.000000 |
| wsrep_cert_index_size | 0 |
| wsrep_cert_interval | 0.000000 |
| wsrep_cluster_conf_id | 4 |
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | 53cae68c-a063-11e7-bf42-b2efbb514b41 |
| wsrep_cluster_status | Primary |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 0.000000 |
| wsrep_connected | ON |
| wsrep_desync_count | 0 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0.000484281/0.000747869/0.000887492/0.000186494/3 |
| wsrep_evs_state | OPERATIONAL |

В выводе важны состояние кластера — On и cluster_size — в данном случае это две ноды.

 

Пробуем создать базу на одном сервер и таблицу в ней на другом

root@galera1:/etc/mysql/conf.d# mysql -u user -ppass

MariaDB [(none)]> create table testcluster;

MariaDB [(none)]> show databases;

+———————+
| Database |
+———————+
| information_schema |
| mysql |
| performance_schema |
| testcluster |
+———————+
4 rows in set (0.00 sec)

 

MariaDB [(none)]> use testcluster;

MariaDB [testcluster]> show tables;

+————————+
| Tables_in_testcluster |
+————————+
|  |
+————————+
0 row in set (0.00 sec)

 

На втором сервере создадим таблицу в  базе, которую только что создали на первом:

root@galera2:~# mysql -u user -ppass

 

MariaDB [(none)]> show databases;

+———————+
| Database |
+———————+
| information_schema |
| mysql |
| performance_schema |
| testcluster |
+———————+
4 rows in set (0.01 sec)

MariaDB [(none)]> use testcluster;

 

MariaDB [testcluster]> CREATE TABLE Persons (
-> PersonID int,
-> LastName varchar(255),
-> FirstName varchar(255),
-> Address varchar(255),
-> City varchar(255)
-> );

Query OK, 0 rows affected (0.09 sec)

 

MariaDB [testcluster]> show tables;

+————————+
| Tables_in_testcluster |
+————————+
| Persons |
+————————+
1 row in set (0.00 sec)

 

Последнюю команду теперь можно потвроить на galera1 и убедиться в том, что репликация работает.

 

Настройка HAPROXY для балансировки нагрузки

HAPROXY будем использовать для того чтобы распределять запросы между galera1 и galera2.

Устанавливаем пакет из репозитория

apt-get install haproxy

 

Раскомменитируем опцию с путем к конфигу и  пропишем ENABLE=1

mcedit /etc/default/haproxy

CONFIG=»/etc/haproxy/haproxy.cfg»
ENABLE=1

 

Настройки для связи с galera задаются в конфигурационном файле — его секции galera

 

mcedit /etc/haproxy/haproxy.cfg

listen galera
bind 123.123.123.123:3306
balance roundrobin
mode tcp
option tcpka
option mysql-check user haproxy
server mariadb1 192.168.0.1:3306 check weight 1
server mariadb2 192.168.0.2:3306 check weight 1

 

Здесь указываем белый адрес — именно к нему подключается приложение, далее haproxy  распределяет запросы на 192.168.0.1 и 192.168.0.2 согласно указанным весам, в данном случае поровну используя алгоритм roundrobin

На этом конфигурация galera cluster с haproxy завершена.

Перезапускаем только что настроенный сервис

/etc/init.d/haproxy restart

 

Стоит учесть, что несмотря на то, что на сервере haproxy нет MySQL он также включен в процесс репликации (его локальный адрес, приндлежащий одному из интерфейсов).

Сейчас можно стартовать galera cluster и подключать к нему вторую ноду с MySQL. Затем запускать приложение указывая в качестве сервера БД  123.123.123.123, логин user и пароль pass.

Для того чтобы понять как haproxy мониторит ситуацию и как распределяет запросы можно останавливать и запускать сервер баз данных на нодах анализируя /var/log/haproxy.log

 

Если остановить MySQL на одной ноде появится сообщение об изменившемся состоянии одного из серверов кластера и ошибке на 4 уровне — при этом 1 сервер согласно записе в логи (что соответсвует действительности) остается активен:

Sep 23 15:16:58 haproxy haproxy[10460]: Server galera/mariadb1 is DOWN, reason: Layer4 connection problem, info: «Connection refused», check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

 

После запуска MySQL состояние сервера в  galera cluster меняетс на UP, активными вновь становятся 2 сервера.

Sep 23 15:17:21 haproxy haproxy[10460]: Server galera/mariadb1 is UP, reason: Layer7 check passed, code: 0, info: «5.5.5-10.2.8-MariaDB-10.2.8+maria~jessie-log», check duration: 1ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

 

Данные при этом синхронизируются и перебоев в работе приложения как и потери информации  не происходит.