Введение
Кластер Галера позволяет создать кластер высокой доступности MySQL / MariaDB кластер баз данных без ущерба для согласованности данных. Благодаря репликации данных между узлами в режиме реального времени Galera обеспечивает постоянную работоспособность даже при отказе отдельных узлов.
В этом подробном руководстве мы рассмотрим шаги по настройке двухузлового кластера Galera на Ubuntu/Debian и CentOS/RHEL Linux.
Предварительные условия
Прежде чем начать, убедитесь, что у вас есть:
- 2 сервера или ВМ с установленными Ubuntu 18.04+/Debian 9+ или CentOS 7+/RHEL 7+.
- Не менее 2 ГБ ОЗУ и 2 vCPU-ядра на каждом узле.
- Корневой доступ к серверам через SSH.
- Сервер MySQL уже установлен на обоих узлах. Рекомендуется версия 5.7+.
- Основные правила брандмауэра настроены на разрешение трафика на портах 3306, 4567, 4568 и 4444.
Большинство команд мы будем выполнять от имени пользователя root или с привилегиями sudo.
Установка Galera и сопутствующих пакетов
Начнем с установки программного обеспечения кластера Galera и других утилит, необходимых для правильного функционирования кластера.
На Ubuntu/Debian
Обновите индексы репозитория apt и установите необходимые пакеты:
$ apt update
$ apt install galera-4 mariadb-server socat python3-mysql.connectorУстанавливается:
- galera-4 — фреймворк кластера Galera
- mariadb-server — Для сервера баз данных MySQL
- socat — Для тестирования & мониторинга кластеров
- python3-mysql.connector — Для соединений с MySQL из Python
На CentOS/RHEL
Включите репозитории EPEL, предоставляющие пакеты Galera:
$ yum install epel-releaseТеперь установите Galera и зависимости:
$ yum install galera mariadb-server rsync socat mysql-connector-pythonПри этом устанавливаются:
- galera — Кластер Galera
- mariadb-server — сервер MySQL
- rsync — Для передачи моментальных снимков SST
- socat — Утилита мониторинга
- mysql-connector-python — Коннектор MySQL на Python
Теперь кластер Galera готов к настройке на обоих узлах.
Настройка MySQL для Galera
Чтобы MySQL мог использовать Galera, нам нужно настроить некоторые параметры в my.cnf.
Откройте файл конфигурации:
$ nano /etc/my.cnfДобавьте следующее под [mysqld]:
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
# Galera settings
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_name="my_galera_cluster"
wsrep_cluster_address="gcomm://node1,node2"
# This Only on Node 1
wsrep_node_address="192.168.1.101"
wsrep_node_name="node1"
# This Only on Node 2
wsrep_node_address="192.168.1.102"
wsrep_node_name="node2"
wsrep_sst_method=rsyncThe wsrep_cluster_address содержит список IP-адресов узлов кластера.
wsrep_node_address и wsrep_node_name должны быть уникальными на каждом сервере.
После внесения изменений сохраните и закройте файл.
Проделайте это на обоих серверах, заменив IP-адреса и имена в соответствии с вашими серверами.
Это настраивает MySQL на использование плагина Galera для репликации.
Запуск кластера Galera
После настройки мы готовы к загрузке кластера.
Запустите MySQL только на первом узле (node1):
$ systemctl start mysql
# or
$ systemctl start mariadbЭто инициализирует кластер Galera.
Проверьте статус MySQL и переменные wsrep:
$ mysql -u root -e "SHOW STATUS LIKE '%wsrep%';"Пример вывода:
+------------------------------+-------------------------------------------------+
| Variable_name | Value |
+------------------------------+-------------------------------------------------+
| wsrep_local_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 0 |
| wsrep_replicated | 0 |
| wsrep_replicated_bytes | 0 |
| wsrep_repl_keys | 0 |
| wsrep_repl_keys_bytes | 0 |
| wsrep_repl_data_bytes | 0 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 1 |
| wsrep_received_bytes | 119 |
| wsrep_local_commits | 0 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_local_cached_downto | 18446744073709551615 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
+------------------------------+-------------------------------------------------+ Это подтверждает, что Galera работает. Обратите внимание, что размер локального кластера сейчас равен 1.
Теперь запустите MySQL на втором узле, чтобы присоединить его к кластеру:
$ systemctl start mysql
# or
$ systemctl start mariadbУбедитесь, что присоединение прошло успешно:
$ mysql -u root -e "SHOW STATUS LIKE '%wsrep%';"Теперь размер кластера должен быть равен 2:
| wsrep_cluster_size |2|Кроме того, выполните команду mysql -e "SHOW STATUS LIKE '%wsrep%';" на узле1 снова, и переменные состояния должны синхронизироваться между обоими узлами.
Наш двухузловой кластер Galera готов!
Тестирование работы кластера
Давайте проверим, что репликация между двумя узлами работает так, как ожидалось.
На узле1 создайте тестовую базу данных и вставьте в нее некоторые данные:
mysql> CREATE DATABASE cluster_test;
mysql> USE cluster_test;
mysql> CREATE TABLE test (id INT, message VARCHAR(20));
mysql> INSERT INTO test VALUES (1, 'Hello Galera');
mysql> SELECT * FROM test;
+------+----------------+
| id | message |
+------+----------------+
| 1 | Hello Galera |
+------+----------------+ Теперь проверьте содержимое той же таблицы на узле2:
mysql> USE cluster_test;
mysql> SELECT * FROM test;
+------+----------------+
| id | message |
+------+----------------+
| 1 | Hello Galera |
+------+----------------+Строка реплицируется с узла1 на узел2, как и ожидалось.
Давайте также протестируем восстановление после отключения. Остановите MySQL на узле1:
$ systemctl stop mysql
# or
$ systemctl stop mariadb На узле2 подключитесь к MySQL и проверьте, что запросы по-прежнему работают:
mysql> USE cluster_test;
mysql> SELECT * FROM test;
+------+----------------+
| id | message |
+------+----------------+
| 1 | Hello Galera |
+------+----------------+Узел2 продолжает работать, несмотря на отключение узла1, поскольку все данные реплицируются.
Восстановите работу узла1:
$ systemctl start mysql
# or
$ systemctl start mariadbОн автоматически синхронизируется с узлом 2. Запустите SHOW STATUS LIKE '%wsrep%'; на обоих узлах, чтобы убедиться, что значения совпадают.
Это демонстрирует высокую доступность, обеспечиваемую Galera!
Мониторинг и управление кластером
Теперь, когда у нас есть работающий кластер Galera, давайте рассмотрим некоторые советы по его мониторингу и управлению.
Проверка состояния кластера
Используйте garbd демон для проверки статистики кластера на высоком уровне:
$ garbd -a gcomm://192.168.1.101,192.168.1.102 -g my_galera_cluster
Galera cluster Node 1/2 info:
evs::protover => 7
evs::uuid => af2a75b4-9e1c-11ed-9838-be4b133a6b15
evs::status => Primary
evs::state => Synced
Galera cluster Node 2/2 info:
evs::protover => 7
evs::uuid => af2a75b4-9e1c-11ed-9838-be4b133a6b15
evs::status => Primary
evs::state => SyncedЭто показывает, что оба узла находятся в состоянии Synced и являются частью одного кластера.
Мониторинг состояния узлов
Используйте mysqladmin для проверки переменных Galera на каждом узле:
$ mysqladmin -uroot -p -h192.168.1.101 variables | grep wsrep
| wsrep_cluster_conf_id | 25 |
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_cluster_status | Primary |
$ mysqladmin -uroot -p -h192.168.1.102 variables | grep wsrep
| wsrep_cluster_conf_id | 25 |
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_cluster_status | Primary | Такие значения, как размер кластера, UUID, статус, должны совпадать на всех узлах.
Проверка состояния передачи SST
Когда к узлу присоединяется новый узел, для синхронизации данных с ним используется State Snapshot Transfer (SST).
Следите за ходом выполнения SST с помощью:
$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_uuid'"
+----------------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------------+--------------------------------------+
| wsrep_local_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
+----------------------------------+--------------------------------------+
$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_comment'"
+-----------------------------------+---------+
| Variable_name | Value |
+-----------------------------------+---------+
| wsrep_local_state_comment | Synced |
+-----------------------------------+---------+Во время выполнения SST, wsrep_local_state_comment будет показывать процент синхронизации.
Проверка состояния восстановления
Когда узел восстанавливается после отключения, его состояние можно проверить с помощью:
mysql>SHOW STATUS WHERE `variable_name` LIKE'wsrep_%';Ищите wsrep_local_state_comment как Recovering или Donor/Desynced во время восстановления.
Таким образом можно отслеживать различные этапы синхронизации и восстановления кластера.
Мониторинг размера кластера
Чтобы проверить количество узлов в кластере:
mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 2 |
+--------------------+-------+Соответствие ожидаемому количеству узлов.
Мы также можем использовать clustercheck скрипт для мониторинга размера кластера:
$ clustercheck
Cluster is CORRECT (2 nodes)
$ Это предупредит, если узлов не хватает или они лишние.
Проверка согласованности узлов
Необходимо проверить состояние кластера, чтобы убедиться, что все узлы содержат одинаковые данные.
Сравнение wsrep_local_state_uuid переменных между узлами указывает на согласованность:
$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_uuid'\G" -h192.168.1.101
*************************** 1. row ***************************
Variable_name: wsrep_local_state_uuid
Value: af2a75b4-9e1c-11ed-9838-be4b133a6b15
$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_uuid'\G" -h192.168.1.102
*************************** 1. row ***************************
Variable_name: wsrep_local_state_uuid
Value: af2a75b4-9e1c-11ed-9838-be4b133a6b15Если UUID совпадает на узлах, данные согласованы.
Проверка состояния соединения
Используйте socat для проверки состояния TCP-соединения между узлами:
$ socat - TCP:192.168.1.101:4567
>
$ socat - TCP:192.168.1.102:4567
>Это подтверждает, что TCP-порт 4567 открыт между узлами для трафика репликации кластера Galera.
Мы также можем использовать MySQL для проверки статуса соединения:
mysql> SHOW STATUS WHERE `variable_name` LIKE '%connection%';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| Slave_connections | 0 |
| Max_used_connections | 2 |
| Aborted_connects | 0 |
| Max_used_connections | 2 |
+-----------------------------+-------+Мониторинг количества открытых соединений для обнаружения проблем.
Это дает представление об общем состоянии кластера и его связности.
Отслеживание истории узлов
История узла может быть полезна при устранении неполадок или анализе событий:
mysql> SHOW STATUS LIKE 'wsrep_local_state_uuid%';
+--------------------------------+--------------------------------------+
| Variable_name | Value |
+--------------------------------+--------------------------------------+
| wsrep_local_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_local_state_uuid_history | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
+--------------------------------+--------------------------------------+Любые UUID кластера в прошлом будут добавлены к wsrep_local_state_uuid_history при таких событиях, как восстановление.
Аналогичным образом отслеживается количество изменений членства в кластере:
mysql> SHOW STATUS LIKE 'wsrep_cluster_size_change%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| wsrep_cluster_size_changes | 1 |
| wsrep_cluster_size_change_history | 1 |
+-------------------------------+-------+Это дает представление об активности кластера во времени.
Используя эти переменные состояния и команды, можно отслеживать правильность работы кластера Galera. Такие проблемы, как отключение узлов, задержка репликации или потеря согласованности, могут быть быстро обнаружены и отлажены.
Настройка Galera Arbitrator (необязательно)
Для кластера из двух узлов необходимо настроить Galera Arbitrator, чтобы избежать сценариев «разделенного мозга». Арбитр — это легкий процесс, который обеспечивает кворум для кластера, чтобы определить, какой узел должен продолжать работу в случае разделения сети.
На третьем сервере установите только galera-4 или galera пакет.
Изменить /etc/my.cnf с:
[mysqld]
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
[galera]
wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102"
wsrep_cluster_name="my_galera_cluster"Начни арбитраж:
$ galera_arbitratorПроверьте журналы по адресу /var/log/mysql/galera.log , чтобы убедиться в успешном подключении к кластеру.
Арбитр теперь будет участвовать в расчете кворума и обеспечивать автоматическое восстановление работоспособности в сценариях с разделенным мозгом. Это предотвращает потерю данных в случае разделения сети.
Заключение
В этом подробном руководстве мы рассмотрели шаги по установке, настройке и мониторингу двухузлового кластера Galera на дистрибутивах Ubuntu/Debian и CentOS/RHEL шаг за шагом с практическими примерами.
Основные выводы::
- Galera позволяет создавать многомастерные кластеры MySQL для обеспечения высокой доступности.
- Репликация на основе строк в реальном времени обеспечивает согласованность.
- Узлы могут динамически добавляться и удаляться.
- Автоматическое присоединение узлов, передача состояния и обработка кворума.
- Мониторинг ключевых переменных состояния, таких как метрики wsrep.
- Арбитр Galera предотвращает сценарии с раздвоением мозга.
Кластер Galera из двух узлов хорошо подходит для сокращения времени простоя и обеспечения избыточности для многих приложений. При необходимости дополнительные узлы можно плавно подключить позже.
Используя это руководство, вы можете развернуть высокодоступные кластеры MySQL с Galera на Ubuntu/Debian и CentOS/RHEL.