Galera Cluster является оптимальным решением для репликации MySQL. Кластер позволяет избежать задержек данных при их копировании с одной ноды на другую в отличие от традиционной Master-Slave репликации.
Galera cluster обеспечивает отказоустойчивость, при выходе из строя одной ноды приложение обслуживает другая или другие. При повторном включении информация на отсутствующей ноде синхронизируется (по-молчанию передача rsync-ом).
В рамках данного материала рассмотрена настройка Galera Cluster на двух нодах и Haproxy, балансирующий нагрузку между ними. Приложение запущено на четвертом сервере.
Galera cluster с MariaDB на Debian
На трех серверах сменим 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 -u root -p
Далее нужно выполнить скрипт безопасной установки, который выведя несколько диалогов подготовит сервер баз данных к работе скорректировав некоторые настройки заданные по-умолчанию (ответ, который нужно давать указан в виде 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-11e | | 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 | | 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.
Данные при этом синхронизируются и перебоев в работе приложения как и потери информации не происходит. Читайте про оптимизацию настроек MySQL.
Она должна быть выполнена для всех нод в кластере.