Во второй части статьи про 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. Дальнейшие действия выполняем одновременно сразу на 3 нодах! Добавляем репозитории на сервер. Обновляем пакеты и ставим cURL: Переходим в домашнюю директорию и скачиваем deb- файл: Устанавливаем: Обновляем пакеты после установки: Теперь нужно включить необходимый нам пакет. В нашем случае это pxc-57. Для этого нам потребуется утилита percona-release, которая была установлена нами ранее. Включаем: Если необходимо включить другой пакет, воспользуйтесь списком всех пакетов на офф.сайте. Не забываем обновить репозитории: Проверяем доступность: Устанавливаем : После установки обязательно останавливаем MySQL: MySQL обязательно должен быть остановлен на всех 3 нодах! Проверяем: Открываем файл конфигурации на первой ноде: 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 текущего сервера в кластере. Вводим номерное обозначение текущей ноды. Пример: Копируем текущие настройки и вставляем на вторую и третью ноду! Во второй и третьей ноде меняем значение wsrep_cluster_address, wsrep_node_address, wsrep_node_name, server_id. Пример второй ноды: Пример третьей ноды: Загружаем кластер. Выполняем на первой ноде: Проверяем статус: Заходим в MySQL: Проверяем статус репликации: Далее создаем пользователя SST. Данного пользователя берем из параметра wsrep_sst_auth в вышеуказанных настройках: Идем на вторую ноду и запускаем ее: Заходим в MySQL и проверяем статус активных нод кластера: Запускаем MySQL на 3 ноде: Заходим в MySQL и проверяем количество нод в кластере: Если результат SQL-запроса выдает 3, значит все три ноды запущены успешно и готовы к работе. Дальнейшее действие - это создать базу и пользователя базы, после чего загрузить в него дамп вашей bitrix-площадки. Данные действия можете выполнять на любой ноде. Любые действия, которые вы выполните на одной ноде продублируются на другие. Также, если вам необходимо поменять параметр MySQL (например, изменить количество оперативной памяти для временных таблиц). Вы можете изменить это динамически SQL- запросом: Параметр изменится на всех нодах. Не забудьте продублировать это в 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: Перечитываем репозитории: Проверяем доступность клиента: Проверяем доступность арбитра: Устанавливаем: Конфигурация арбитра по умолчанию находится по адресу: /etc/default/garbd. Открываем: GALERA_NODES - добавляем IP адреса нод кластера. GALERA_GROUP - название вашего кластера. Пример: После чего запускаем garbd: Для проверки работы арбитра, выведите количество рабочих нод на первой либо второй ноде: Если вывод SQL-запроса будет цифра два, смотрите status или log- файл в /var/log/garbd. Частая ошибка: Проверьте GALERA_GROUP - правильно ли там указано название. Название сравните с параметром wsrep_cluster_name на 1 и 2 ноде в /etc/mysql/percona-xtradb-cluster.conf.d/wsrep.cnf. Если у вас показывается цифра 3, значит, вы настроили кластер правильно, у вас все работает! Percona Monitoring and Management - это удобный dashboard для мониторинга вашего кластера. Демо-версия по ссылке: PMM. PMM позволяет отслеживать загруженность серверов. Отслеживать доступность. Отслеживать запросы к БД. И еще много всего! Нам понадобится PMM Client и PMM Server. Установка PMM Server: PMM Server легче всего запустить в Docker. Поэтому нам потребуется поставить Docker на сервер и запустить docker-compose up. В данном compose вам необходимо поменять  ports, SERVER_USER и SERVER_PASSWORD. Если у вас установлен NGINX, вы можете настроить проксирование напрямую в контейнер без открытия порта на хосте. Также, для PMM Client можно указать IP адрес. Установка PMM Client: Клиент можно также запустить в контейнере. Но мы запустим на хосте. Скачиваем репозиторий и устанавливаем: Обновляем репозитории: Устанавливаем клиент: Регистрируем PMM Client. Выполняем: --server-url - указываем ваше имя пользователя и пароль, после чего IP адрес контейнера. Если вы не указывали IP адрес контейнера в docker-compose, узнать IP можно с помощью команды docker inspect. Пример: После регистрации необходимо добавить ноды MySQL. Для нод необходим пользователь мониторинга. Поэтому создаем его в вашем MySQL: Добавляем ноду mysql: Пример: Так добавляем каждую ноду. Более подробно на офф.сайте. После добавления всех нод. Вы можете обращаться к dashboard по адресу: Пример: В данной статье мы с вами настроили отказоустойчивый кластер MySQL, который нам пригодится в дальнейшем. В следующей статье мы с вами развернем ProxySQL, Ceph, поговорим про отказоустойчивость и про тесты. Надеемся, статья была полезной. Вопросы можете задавать в комментариях. Также подписывайтесь на наш telegram-канал DevOps FM - там много полезного для DevOps-инженеров и системных администраторов. Рекомендации для чтения: Зашита от dos/ddos. Курс yandex практикум. 10 частых ошибок в настройке nginx. Неудачные миграции в облако.  Системный администратор