Во второй части статьи про bitrix-кластер мы будем рассматривать настройку percona xtradb cluster mysql 5.7, настройку арбитратора, настройку удобного dashboard.
Если вы не читали первую часть, с ней можно ознакомиться по ссылке: Тот самый bitrix-кластер. Начало.
Более подробно с информацией о том, что такое Percona, и с чем её едят, можно ознакомится на офф.сайте.
Минимальные требования:
На данный момент у вас должно быть 6 нод. 3 mysql и 3 php.
Все сервера MySQL должны быть равноценны. Одинаковое количество CPU, RAM.
Все сервера PHP должны быть равноценны. Одинаковое количество CPU, RAM.
Должна быть проведена базовая настройка сервера.
На нодах MySQL у вас должны быть открыты порты: 3306 4444 4567 4568
Все настройки в статье ведутся на ОС Ubuntu 20.04.4 LTS \n \l.
Сервера для тестов (в рамках этой статьи брали в Yandex Cloud).
Установка Percona
Убедитесь, что ваша ОС поддерживается: Percona.
Дальнейшие действия выполняем одновременно сразу на 3 нодах!
Добавляем репозитории на сервер.
Обновляем пакеты и ставим cURL:
sudo apt update
sudo apt install curl
Переходим в домашнюю директорию и скачиваем deb- файл:
cd
curl -O https://repo.percona.com/apt/percona-release_latest.generic_all.deb
Устанавливаем:
sudo apt install gnupg2 lsb-release ./percona-release_latest.generic_all.deb
Обновляем пакеты после установки:
apt update
Теперь нужно включить необходимый нам пакет. В нашем случае это pxc-57. Для этого нам потребуется утилита percona-release, которая была установлена нами ранее.
Включаем:
percona-release enable pxc-57
* Enabling the Percona XtraDB Cluster 5.7 repository
<*> All done!
==> Please run "apt-get update" to apply changes
Если необходимо включить другой пакет, воспользуйтесь списком всех пакетов на офф.сайте.
Не забываем обновить репозитории:
apt update
Проверяем доступность:
:~# apt-cache search percona-xtradb-cluster-57
percona-xtradb-cluster-57 - Percona XtraDB Cluster with Galera
Устанавливаем :
apt install percona-xtradb-cluster-57
После установки обязательно останавливаем MySQL:
service mysql stop
MySQL обязательно должен быть остановлен на всех 3 нодах!
Проверяем:
~# service mysql status
● mysql.service - LSB: Start and stop the mysql (Percona XtraDB Cluster) daemon
Loaded: loaded (/etc/init.d/mysql; generated)
Active: inactive (dead) since Tue 2022-09-13 08:22:43 UTC; 8s ago
Docs: man:systemd-sysv-generator(8)
Process: 5793 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
Настройка нод кластера
Открываем файл конфигурации на первой ноде:
mcedit /etc/mysql/percona-xtradb-cluster.conf.d/wsrep.cnf
[mysqld]
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_cluster_name=
wsrep_cluster_address=gcomm://
wsrep_node_name=
wsrep_node_address=
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=
pxc_strict_mode=ENFORCING
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
server_id = 1
wsrep_provider - путь до файла поставщика wsrep, чтобы включить функции репликации. Если закомментировать данную строчку, то MySQL запуститься как обычный MySQL без репликации. Оставляем по умолчанию.
wsrep_cluster_name - название вашего кластера. Вводим название cluster.
wsrep_cluster_address - локальные ip- адреса серверов кластера.
Вводим три3 IP адресеip- адреса всех нод кластера.
wsrep_node_name - название текущей ноды.
wsrep_node_address - IP адресеip адрес текущей ноды.
wsrep_sst_method - метод передачи снимков состояния нод кластера. Оставляем по умолчанию.
wsrep_sst_auth - пользователь для передачи снимков состояния. Придумываем пользователя и пароль к нему.
pxc_strict_mode - строгий режим PXC, который выполняет ряд проверок при запуске и во время выполнения. Меняем на DISABLED. Иначе bitrix будет ругаться.
binlog_format - формат бинарных логов. Оставляем по умолчанию.
default_storage_engine - движок MySQL по умолчанию. Оставляем по умолчанию.
innodb_autoinc_lock_mode - режим блокировки таблиц InnoDB. Оставляем по умолчанию.
server_id - ID текущего сервера в кластере. Вводим номерное обозначение текущей ноды.
Пример:
[mysqld]
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_cluster_name=pxc-cluster
wsrep_cluster_address=gcomm://10.129.0.28,10.129.0.21,10.129.0.27
wsrep_node_name=test_cluster_node_1
wsrep_node_address=10.129.0.28
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:ThuuKu9zohJie4u
pxc_strict_mode=ENFORCING
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
server_id=1
Копируем текущие настройки и вставляем на вторую и третью ноду!
Во второй и третьей ноде меняем значение wsrep_cluster_address, wsrep_node_address, wsrep_node_name, server_id.
Пример второй ноды:
[mysqld]
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_cluster_name=test-cluster
wsrep_cluster_address=gcomm://10.129.0.28,10.129.0.21,10.129.0.27
wsrep_node_name=test_cluster_node_2
wsrep_node_address=10.129.0.21
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:ThuuKu9zohJie4u
pxc_strict_mode=ENFORCING
binlog_format=ROW
default_storage_engine=InnoDB
server_id=2
Пример третьей ноды:
[mysqld]
wsrep_provider=/usr/lib/libgalera_smm.so
wsrep_cluster_name=test-cluster
wsrep_cluster_address=gcomm://10.129.0.28,10.129.0.21,10.129.0.27
wsrep_node_name=test_cluster3
wsrep_node_address=10.129.0.27
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:ThuuKu9zohJie4u
pxc_strict_mode=ENFORCING
binlog_format=ROW
default_storage_engine=InnoDB
server_id=3
Загружаем кластер.
Выполняем на первой ноде:
/etc/init.d/mysql bootstrap-pxc
* Bootstrapping Percona XtraDB Cluster database server mysqld [ OK ]
Проверяем статус:
systemctl status mysql
● mysql.service - LSB: Start and stop the mysql (Percona XtraDB Cluster) daemon
Loaded: loaded (/etc/init.d/mysql; generated)
Active: active (exited) since Tue 2022-09-13 08:34:17 UTC; 19s ago
Docs: man:systemd-sysv-generator(8)
Process: 6512 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCCESS)
Заходим в MySQL:
mysql -u root -p
Проверяем статус репликации:
show status like 'wsrep%';
mysql> show status like 'wsrep%';
+----------------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------------+--------------------------------------+
| wsrep_local_state_uuid | 20c08741-333d-11ed-b654-ca4b69f4db8d |
| wsrep_protocol_version | 9 |
| wsrep_last_applied | 0 |
| 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 | 2 |
| wsrep_received_bytes | 148 |
| wsrep_local_commits | 0 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 1 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 1 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_local_cached_downto | 0 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_flow_control_interval | [ 100, 100 ] |
| wsrep_flow_control_interval_low | 100 |
| wsrep_flow_control_interval_high | 100 |
| wsrep_flow_control_status | OFF |
| wsrep_flow_control_active | false |
| wsrep_flow_control_requested | false |
| wsrep_cert_deps_distance | 0.000000 |
| wsrep_apply_oooe | 0.000000 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 0.000000 |
| wsrep_apply_waits | 0 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 0.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 0 |
| wsrep_cert_bucket_count | 22 |
| wsrep_gcache_pool_size | 1320 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.000000 |
| wsrep_open_transactions | 0 |
| wsrep_open_connections | 0 |
| wsrep_ist_receive_status | |
| wsrep_ist_receive_seqno_start | 0 |
| wsrep_ist_receive_seqno_current | 0 |
| wsrep_ist_receive_seqno_end | 0 |
| wsrep_incoming_addresses | 10.129.0.28:3306 |
| wsrep_cluster_weight | 1 |
| wsrep_desync_count | 0 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0/0/0/0/0 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | b1aca01d-333e-11ed-83ec-0e1ba8a09f8c |
| wsrep_gmcast_segment | 0 |
| wsrep_cluster_conf_id | 1 |
| wsrep_cluster_size | 1 |
| wsrep_cluster_state_uuid | 20c08741-333d-11ed-b654-ca4b69f4db8d |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 0 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 3.61(rf47405c) |
| wsrep_ready | ON |
+----------------------------------+--------------------------------------+
75 rows in set (0.00 sec)
Далее создаем пользователя SST. Данного пользователя берем из параметра wsrep_sst_auth в вышеуказанных настройках:
CREATE USER 'ИМЯ ПОЛЬЗОВАТЕЛЯ'@'localhost' IDENTIFIED BY 'ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;
Идем на вторую ноду и запускаем ее:
/etc/init.d/mysql start
Заходим в MySQL и проверяем статус активных нод кластера:
mysql -u root -p
show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 2 |
+--------------------+-------+
1 row in set (0.00 sec)
Запускаем MySQL на 3 ноде:
/etc/init.d/mysql start
Заходим в MySQL и проверяем количество нод в кластере:
mysql -u root -p
show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.00 sec)
Если результат SQL-запроса выдает 3, значит все три ноды запущены успешно и готовы к работе. Дальнейшее действие - это создать базу и пользователя базы, после чего загрузить в него дамп вашей bitrix-площадки. Данные действия можете выполнять на любой ноде. Любые действия, которые вы выполните на одной ноде продублируются на другие. Также, если вам необходимо поменять параметр MySQL (например, изменить количество оперативной памяти для временных таблиц). Вы можете изменить это динамически SQL- запросом:
SET GLOBAL query_cache_size = 40000;
Параметр изменится на всех нодах.
Не забудьте продублировать это в mysql.cnf на всех нодах!
Рубрика “Вопрос ответ”:
Как восстанавливать репликацию, если упала одна из нод?
Ответ: Все восстановится автоматически. Вам необходима лишь одна рабочая нода, и все что нужно сделать - это запустить MySQL на упавшей ноде.
Если упали сразу все ноды Percona XtraDB Cluster?
Ответ: На эту тему, есть отличный гайд у Percona: ГАЙД.
Если необходимо поменять параметры, которые нельзя изменить динамически?
Ответ: По очереди повторяете на каждой ноде:
Меняете параметр в my.cnf.
Останавливаете mysql.
Запускаете mysql.
Если вам будет достаточно лишь 2 рабочие ноды?
Ответ: Тогда вам потребуется арбитр, который заменит вам одну ноду.
Арбитр
Внимание: Если у вас три рабочих ноды, смело пропускайте этот пункт.
Итак, что такое арбитр?
Арбитр - это член кластера без передаваемых данных и БД. Он участвует лишь в споре актуальности данных. Арбитр требуется всякий раз, когда существует возможность сценария разделения сети. Он используется, чтобы решить, какие из уцелевших настроек узла данных могут продолжать работать. Любые узлы данных, которые не будут одобрены арбитром, будут отключены, чтобы предотвратить split-brain от происходящего.
В Perconа имеется и используется арбитр garbd.
Для установке необходимо добавить репозитории Percona. Как это сделать, можно смотреть в начале статьи.
Для начала необходимо установить клиент MySQL percona-server-client-5.7.
Для этого подключаем пакет Percona Server 5.7:
percona-release enable ps-57
* Enabling the Percona Server 5.7 repository
<*> All done!
==> Please run "apt-get update" to apply changes
Перечитываем репозитории:
apt update
Проверяем доступность клиента:
apt-cache search percona-server-client-5.7
percona-server-client-5.7 - Percona Server database client binaries
Проверяем доступность арбитра:
apt-cache search percona-xtradb-cluster-garbd
percona-xtradb-cluster-garbd-5.7 - Garbd components of Percona XtraDB Cluster
percona-xtradb-cluster-garbd-debug-5.7 - Debugging package for Percona XtraDB Cluster Garbd
Устанавливаем:
apt install percona-server-client-5.7 percona-xtradb-cluster-garbd-5.7
Конфигурация арбитра по умолчанию находится по адресу: /etc/default/garbd.
Открываем:
mcedit /etc/default/garbd
# Copyright (C) 2012 Codership Oy
# This config file is to be sourced by garb service script.
# A comma-separated list of node addresses (address[:port]) in the cluster
GALERA_NODES=
# Galera cluster name, should be the same as on the rest of the nodes.
GALERA_GROUP=
# Optional Galera internal options string (e.g. SSL settings)
# see http://galeracluster.com/documentation-webpages/galeraparameters.html
# GALERA_OPTIONS=""
# Log file for garbd. Optional, by default logs to syslog
# Deprecated for CentOS7, use journalctl to query the log for garbd
GALERA_NODES - добавляем IP адреса нод кластера.
GALERA_GROUP - название вашего кластера.
Пример:
GALERA_NODES="10.129.0.28:4567 10.129.0.21:4567"
GALERA_GROUP="test-cluster"
# GALERA_OPTIONS=""
После чего запускаем garbd:
/etc/init.d/garbd start
Для проверки работы арбитра, выведите количество рабочих нод на первой либо второй ноде:
show status like 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.00 sec)
Если вывод SQL-запроса будет цифра два, смотрите status или log- файл в /var/log/garbd.
Частая ошибка:
WARN: handshake with b1aca01d tcp://10.129.0.28:4567 failed: 'invalid group'
WARN: handshake with af15c58d tcp://10.129.0.21:4567 failed: 'invalid group'
Проверьте GALERA_GROUP - правильно ли там указано название. Название сравните с параметром wsrep_cluster_name на 1 и 2 ноде в /etc/mysql/percona-xtradb-cluster.conf.d/wsrep.cnf.
Если у вас показывается цифра 3, значит, вы настроили кластер правильно, у вас все работает!
Percona Monitoring and Management
Percona Monitoring and Management - это удобный dashboard для мониторинга вашего кластера. Демо-версия по ссылке: PMM.
PMM позволяет отслеживать загруженность серверов. Отслеживать доступность. Отслеживать запросы к БД. И еще много всего!
Нам понадобится PMM Client и PMM Server.
Установка PMM Server:
PMM Server легче всего запустить в Docker. Поэтому нам потребуется поставить Docker на сервер и запустить docker-compose up.
docker-compose для pmm-client:
version: '2'
services:
pmm-data:
image: percona/pmm-server:latest
container_name: pmm-data
volumes:
- ./prometheus/data:/opt/prometheus/data
- ./consul-data:/opt/consul-data
- ./mysql:/var/lib/mysql
- ./grafana:/var/lib/grafana
entrypoint: /bin/true
pmm-server:
image: percona/pmm-server:latest
container_name: pmm-server
ports:
- '81:80' #### 81 меняете на любой удобный вам порт.
restart: always
environment:
- SERVER_USER=admin #### название root пользователя для dashboard
- SERVER_PASSWORD=eiHohw2aePee5ei ##### пароль для root пользователя.
- METRICS_RETENTION=720h
- METRICS_MEMORY=4194304
- METRICS_RESOLUTION=1s
- QUERIES_RETENTION=30
volumes_from:
- pmm-data
В данном compose вам необходимо поменять ports
, SERVER_USER
и SERVER_PASSWORD
. Если у вас установлен NGINX, вы можете настроить проксирование напрямую в контейнер без открытия порта на хосте. Также, для PMM Client можно указать IP адрес.
Установка PMM Client:
Клиент можно также запустить в контейнере. Но мы запустим на хосте.
Скачиваем репозиторий и устанавливаем:
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
dpkg -i percona-release_latest.generic_all.deb
Обновляем репозитории:
apt update
Устанавливаем клиент:
apt install -y pmm2-client
Регистрируем PMM Client.
Выполняем:
pmm-admin config --server-insecure-tls --server-url=http://x:x@x
--server-url - указываем ваше имя пользователя и пароль, после чего IP адрес контейнера. Если вы не указывали IP адрес контейнера в docker-compose, узнать IP можно с помощью команды docker inspect.
Пример:
pmm-admin config --server-insecure-tls --server-url=http://admin:eiHohw2aePee5ei@172.18.0.3:81
После регистрации необходимо добавить ноды MySQL.
Для нод необходим пользователь мониторинга. Поэтому создаем его в вашем MySQL:
CREATE USER 'ИМЯ ПОЛЬЗОВАТЕЛЯ'@'localhost' IDENTIFIED BY 'ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ' WITH MAX_USER_CONNECTIONS 10;
GRANT SELECT, PROCESS, REPLICATION CLIENT, RELOAD ON *.* TO 'pmm'@'localhost';
Добавляем ноду mysql:
pmm-admin add mysql --username=ИМЯ ПОЛЬЗОВАТЕЛЯ --password=ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ --server-url=http://имя пользователя:пароль пользователя@172.18.0.3 --query-source=perfschema Название ноды адрес ноды:3306
Пример:
pmm-admin add mysql --username=pmm --password=eiHohw2aePee5ei2 --server-url=http://admin:eiHohw2aePee5ei@172.18.0.3 --query-source=perfschema test_node_1 10.128.0.26:3306
Так добавляем каждую ноду.
Более подробно на офф.сайте.
После добавления всех нод. Вы можете обращаться к dashboard по адресу:
http://ip адрес сервера:порт
Пример:
http://8.8.8.8:81
В данной статье мы с вами настроили отказоустойчивый кластер MySQL, который нам пригодится в дальнейшем. В следующей статье мы с вами развернем ProxySQL, Ceph, поговорим про отказоустойчивость и про тесты.
Надеемся, статья была полезной. Вопросы можете задавать в комментариях.
Также подписывайтесь на наш telegram-канал DevOps FM - там много полезного для DevOps-инженеров и системных администраторов.
Рекомендации для чтения: