MARIADB И GALERA CLUSTER

Galera Cluster for MySQL

14.03.2025
Официальный сайт проекта galeracluster.com
Cтатью писал Игольников Игорь.

MariaDB Galera Cluster — это кластерное решение для базы данных MariaDB, которое обеспечивает высокую доступность и синхронную репликацию данных между несколькими узлами. Оно основано на технологии Galera, разработанной компанией Codership, и интегрировано в MariaDB начиная с версии 10.1. Это решение идеально подходит для сценариев, где требуется минимальная задержка репликации, отказоустойчивость и возможность записи на любой узел кластера.

Основные характеристики:

1. Мультимастер архитектура: Все узлы в кластере являются одновременно и мастером, и репликой. Это значит, что вы можете выполнять операции чтения и записи на любом узле, а изменения будут автоматически синхронизированы со всеми остальными.
   Отсутствует традиционное разделение на "master" и "slave", как в классической репликации MySQL.
2. Синхронная репликация: Используется метод сертификации (certification-based replication): транзакция фиксируется только после того, как все узлы подтверждают её успешное применение. Это гарантирует отсутствие задержек репликации (slave lag) и потерянных данных при сбое узла.
3. Поддерживаемые движки: Основной движок — InnoDB (обязателен для полной функциональности). Экспериментальная поддержка MyISAM и Aria (с MariaDB 10.6).
4. Платформа: Работает только на Linux.
5. Автоматическое управление узлами: При добавлении нового узла он автоматически синхронизируется с кластером через механизм State Snapshot Transfer (SST) или Incremental State Transfer (IST). Узлы, которые выходят из строя, автоматически исключаются из кластера.

Как работает Galera Cluster?

• Wsrep API: Интерфейс между сервером MariaDB и плагином Galera. Он передаёт набор записей (write-set) — данные и информацию о блокировках — для репликации.
• Сертификация: Каждый узел проверяет write-set на конфликты с другими транзакциями. Если конфликтов нет, транзакция применяется ко всем узлам.
• Групповая коммуникация: Узлы обмениваются данными через плагины групповой коммуникации (например, gcomm), обеспечивая согласованность.

Пример процесса:

• Клиент записывает данные на одном узле.
• Транзакция формирует write-set и отправляется всем узлам.
• Узлы проверяют и подтверждают транзакцию.
• После успешной сертификации данные применяются ко всем узлам одновременно.

Преимущества:

• Высокая доступность: Нет единой точки отказа, так как любой узел может принимать запросы.
• Нулевая потеря данных: Синхронность гарантирует, что данные одинаковы на всех узлах.
• Простота масштабирования: Добавление узлов не требует сложной ручной настройки.
• Гибкость: Подходит для облачных сред и распределённых дата-центров.
• Прозрачность для приложений: Не нужно разделять операции чтения и записи.

Ограничения:

• Требуется минимум 3 узла: Для кворума и избежания "split-brain" (разделения кластера).
• Ограничения InnoDB: Не поддерживает некоторые операции, например, LOCK TABLES или XA-транзакции.
• Производительность: Зависит от самого медленного узла в кластере, так как синхронность требует координации.
• Размер транзакций: Большие транзакции (например, LOAD DATA) могут замедлить работу.

Установка mariadb-server:

sudo apt update
sudo apt install -y software-properties-common dirmngr apt-transport-https curl
из официального репозитория:
curl -LsSO https://r.mariadb.com/downloads/mariadb_repo_setup
chmod +x mariadb_repo_setup
./mariadb_repo_setup
sudo apt update && sudo apt upgrade -y
sudo apt install -y mariadb-server mariadb-client
sudo systemctl start mariadb
sudo systemctl enable mariadb
sudo systemctl status mariadb
mariadb --version
sudo apt install -y mariadb-server galera-4

В нашем случаи дистрибутив Debian 12 и MariaDB 10

Для примера я создам 3 контейнера для будущего кластера из 3 нод.

1. Далее мы создадим отдельный файл конфигурации в директории /etc/mysql/conf.d/galera.cnf
   Ниже мы рассмотрим основной набор команд, которые можно использовать в файле galera.cnf. Для первого запуска нашего кластера.
   [mysqld]
   #Основная конфигурация для mysql
   binlog_format=ROW
   default-storage-engine=innodb
   innodb_autoinc_lock_mode=2
   bind-address=0.0.0.0
   # Основная конфигурация для Galera
   wsrep_on=ON
   wsrep_provider=/usr/lib/galera/libgalera_smm.so
   wsrep_cluster_name="my_galera_cluster"
   wsrep_cluster_address="gcomm://192.168.1.1,192.168.1.2,192.168.1.3"
   default_storage_engine=InnoDB
   wsrep_sst_method=rsync
   # Основная конфигурация ноды.
   wsrep_node_address="192.168.1.1"
   wsrep_node_name="DB-CL-01"
2. Итак, теперь нам необходимо создать аналогичные файлы конфигурации для остальных наших серверов.
3. После того как все файлы конфигурации были успешно созданы, необходимо остановить службу MariaDB с помощью команды service mariadb stop
4. На первой ноде запускаем наш кластер командой galera_new_cluster
5. Затем мы должны запустить службу на остальных нодах, используя следующую команду service mariadb start
6. Чтобы убедиться, что наш кластер запущен и все узлы подключены к системе, выполните следующую команду: mysql -e "SHOW STATUS LIKE 'wsrep%';"
   нас интересуют строки wsrep_incoming_addresses и wsrep_cluster_size
   wsrep_incoming_addresses = 192.168.1.1,192.168.1.2,192.168.1.3
   wsrep_cluster_size = 3

На этом наш основной путь завершается.

Работа даже на одной ноде.

1. Если мы хотим, чтобы наше приложение функционировало даже в случае потери двух из трёх нод, мы можем следовать инструкции, представленной ниже.:
   # Основная конфигурация для Galera
   wsrep_provider_options="pc.ignore_quorum=1; pc.ignore_sb=1"
   Параметр позволяет узлу продолжать работу даже при потере кворума, то есть даже если количество узлов в кластере, способных голосовать, становится ниже установленного порога (обычно больше половины узлов).
   pc.ignore_quorum=1
   Параметр отключает проверку на разделение (split-brain). Это означает, что если узлы потеряют связь друг с другом, они продолжат работать независимо.
   pc.ignore_sb=1
   Это может быть полезно в ситуациях, когда потеря кворума временная (например, из-за сетевых проблем) или для предотвращения остановки работы кластера в случае аварийного отключения части узлов.
2. Из первой части понятно, что эта функция позволит нам работать даже с небольшим количеством серверов. Тем не менее, вам следует учесть возможность рассинхронизации данных. Чтобы избежать этой проблемы, я бы предложил установить балансировку, которая будет блокировать запись данных во время простоя сервера. Кроме того, можно запустить скрипты, которые помогут вернуть ноду в кластер после её утраты.
   Можно перезапустить службу service mariadb restart для сервера которые были ранее не доступны. Так-же можно выполнить команду mysql -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=1';" Значение "1" номер узла объявляющимся основным для инициализации кластера.

Более подробную информацию о параметрах wsrep_ можно узнать с официального сайта разработчика.