Как настроить синхронную репликацию с несколькими мастерами MariaDB Galera с использованием Debian 10
На этой странице
- Требования
- Шаг 1. Установка MariaDB
- Шаг 2. Настройка MariaDB
- Шаг 3. Начальная загрузка кластера
- Шаг 4. Тестирование
- Шаг 5. Советы по устранению неполадок
- Дополнительная информация
MariaDB предлагает два разных решения для обеспечения высокой доступности (HA) и кластеризации. Первый — это стандартная репликация master/slave MariaDB, которую можно настроить в различных топологиях, в основном для балансировки нагрузки, высокой доступности и резервного копирования. Второй — MariaDB Galera, решение для синхронной кластеризации с несколькими мастерами. Его основные особенности заключаются в следующем:
- Несколько мастеров: все узлы в кластере Galera могут выполнять операции чтения и записи, что обеспечивает лучшую масштабируемость.
- Узлы могут присоединяться к кластеру автоматически и исключаются в случае сбоя.
- Репликация Galera является синхронной, то есть изменения на одном узле гарантированно применяются на других узлах. Теоретически это гарантирует, что при отказе узла данные не будут потеряны.
Это руководство проведет вас через установку MariaDB и ее настройку в кластере Galera. Мы будем использовать три узла Debian 10 для демонстрации, хотя можно использовать любое количество (≥3) узлов. Настройка двух узлов в кластере Galera технически возможна, но не обеспечивает отказоустойчивости, поскольку неисправный узел приведет к остановке другого узла.
Требования
- Три или более экземпляра Debian 10.
- Доступ к пользователю root или любому пользователю с привилегиями sudo.
- Должна быть установлена переменная среды $EDITOR.
ПРИМЕЧАНИЕ. Кластеры Galera могут работать через глобальную или локальную сеть. Если ваши узлы находятся в частной сети, используйте частные IP-адреса там, где это применимо. В противном случае следует использовать адреса WAN.
Если вы используете пользователя sudo, откройте и используйте корневую оболочку на время этой настройки, используя:
sudo -s
Шаг 1: Установка MariaDB
Этот шаг должен быть выполнен на всех узлах.
Используйте следующие команды для установки MariaDB, библиотеки Galera и Rsync. Последний используется Galera.
apt update apt install -y mariadb-server mariadb-client galera-3 rsync
Убедитесь, что служба MariaDB включена:
systemctl enable mariadb.service
Защитите свои экземпляры MariaDB с помощью скрипта mysql_secure_installation:
mysql_secure_installation
Ответьте на вопросы, как показано ниже, и убедитесь, что вы выбрали надежный пароль для пользователя root MySQL.
Enter current password for root (enter for none): Press <Enter> Set root password? [Y/n] y New password: your_password Re-enter new password: your_password Remove anonymous users? [Y/n] y Disallow root login remotely? [Y/n] y Remove test database and access to it? [Y/n] y Reload privilege tables now? [Y/n] y All done! If you've completed all of the above steps, your MariaDB installation should now be secure.
Шаг 2: Настройка MariaDB
Этот шаг должен быть выполнен на всех узлах.
Остановите службу MariaDB на всех узлах:
systemctl stop mariadb.service
По умолчанию демон MariaDB прослушивает соединения только на локальном хосте. Для того, чтобы кластер работал, это должно быть изменено на доступный извне адрес. Для этого отредактируйте файл параметров /etc/mysql/mariadb.conf.d/50-server.cnf:
$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf
Найдите следующую строку:
bind-address = 127.0.0.1
Если вы используете частную сеть для кластера и не хотите предоставлять доступ к MariaDB другим сетям (например, WAN), укажите локальный IPv4-адрес для каждого узла. В противном случае используйте 0.0.0.0, который указывает MariaDB прослушивать все интерфейсы. Например:
bind-address = 0.0.0.0
Сохраните изменения и выйдите из текстового редактора.
Теперь мы настроим параметры, связанные с кластером. Создайте новый файл опций:
$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf
Введите следующую разумную конфигурацию в файл, заменив IP-адреса. Он должен быть одинаковым на всех узлах.
[galera]
wsrep_on = on wsrep_provider = /lib/galera/libgalera_smm.so wsrep_cluster_address = gcomm://192.0.2.1,192.0.2.2,192.0.2.3 wsrep_cluster_name = galera_cluster_0 default_storage_engine = InnoDB innodb_autoinc_lock_mode = 2 innodb_doublewrite = 1 binlog_format = ROW
- wsrep_on=on включает репликацию набора записей, базовую функциональность, используемую Galera.
- wsrep_provider указывает путь к библиотеке galera. Он предоставляется пакетом galera-3 по адресу /lib/galera/libgalera_smm.so в Debian 10.
- wsrep_cluster_address должен содержать хотя бы один адрес другого члена кластера. Рекомендуется перечислить всех членов кластера. Особого порядка не требуется.
- wsrep_cluster_name должно быть уникальным для кластера и одинаковым на всех узлах одного и того же кластера galera.
- Остальные параметры необходимы для правильной работы Galera, и их не следует изменять.
Шаг 3: Начальная загрузка кластера
Прежде чем продолжить, убедитесь, что MariaDB остановлен/неактивен на всех узлах:
systemctl status mariadb.service
Чтобы запустить кластер, узел сначала должен его создать. В Debian 10 это можно сделать с помощью скрипта galera_new_cluster. Сценарий должен выполняться только на одном узле и только один раз для инициализации кластера.
galera_new_cluster
Это запустит MariaDB на текущем узле. Убедитесь, что он работает с:
systemctl status mariadb.service
Затем запустите MariaDB на других узлах с помощью:
systemctl start mariadb.service
Теперь кластер должен работать.
Шаг 4: Тестирование
Чтобы убедиться, что кластер работает должным образом, выберите любой узел и войдите в MariaDB:
mysql -u root -p
Выполните следующую инструкцию для создания базы данных:
> CREATE DATABASE test0; > \q
Затем проверьте наличие этой новой базы данных на всех остальных узлах:
mysql -u root -p -e "SHOW DATABASES;"
Приведенная выше команда должна вернуть список, содержащий test0:
+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test0 | +--------------------+
Возможно, вы захотите провести более тщательное тестирование, записав в кластер с каждого узла. Когда вы будете удовлетворены результатами тестирования, удалите из кластера все ненужные базы данных. Можно использовать любой узел.
mysql -u root -p -e "DROP DATABASE test0;"
Шаг 5: Советы по устранению неполадок
Используйте следующий запрос для просмотра информации о текущем состоянии узла/кластера:
mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_REPL_LATENCY','WSREP_EVS_DELAYED','WSREP_READY');"
Исправный кластер из 3 узлов должен возвращать следующее:
+---------------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------------+----------------+ | WSREP_CLUSTER_SIZE | 3 | | WSREP_CLUSTER_STATUS | Primary | | WSREP_EVS_DELAYED | | | WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 | | WSREP_LOCAL_STATE_COMMENT | Synced | | WSREP_READY | ON | +---------------------------+----------------+
- WSREP_CLUSTER_SIZE представляет текущее количество узлов в компоненте кластера.
- WSREP_CLUSTER_STATUS представляет состояние компонента кластера, а не кластера в целом.
- WSREP_EVS_DELAYED показывает список узлов, которые задерживаются. От здоровых кластеров ожидается пустое значение.
- WSREP_EVS_REPL_LATENCY показывает задержку репликации в формате min/avg/max/stddev/samplesize. Значения отображаются в секундах. Очень высокие задержки могут привести к снижению производительности.
- WSREP_LOCAL_STATE_COMMENT показывает текущее состояние узла.
- WSREP_READY указывает, может ли узел принимать запросы.
Когда узел в кластере из 3 узлов теряет связь, кластер разделяется на основной компонент, состоящий из 2 узлов, и неосновной компонент. Основной компонент не пострадал от сбоя и продолжает работать в обычном режиме. С точки зрения неосновного компонента приведенный выше запрос вернет следующее:
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------------+--------------------------------------------------------------------------------------------------------------------------------+ | WSREP_CLUSTER_SIZE | 1 | | WSREP_CLUSTER_STATUS | non-Primary | | WSREP_EVS_DELAYED | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907:tcp://192.0.2.1:4567:3,a421be89-fe7d-11e9-a91e-7e62f7562e58:tcp://192.0.2.3:4567:2 | | WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 | | WSREP_LOCAL_STATE_COMMENT | Initialized | | WSREP_READY | OFF | +---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
Обратите внимание на значение WSREP_EVS_DELAYED, которое указывает на проблемы с подключением к другим узлам.
На узлах основных компонентов тот же запрос возвращает:
+---------------------------+----------------------------------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------------+----------------------------------------------------------------+ | WSREP_CLUSTER_SIZE | 2 | | WSREP_CLUSTER_STATUS | Primary | | WSREP_EVS_DELAYED | a2217526-fe7d-11e9-8692-1f2f0cdb403d:tcp://192.0.2.2:4567:2 | | WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 | | WSREP_LOCAL_STATE_COMMENT | Synced | | WSREP_READY | ON | +---------------------------+----------------------------------------------------------------+
Для восстановления после отказа одного узла ручное вмешательство не требуется. Когда отказавший узел повторно подключается к кластеру, он автоматически синхронизируется с кластером.
Дополнительная информация
Дополнительные параметры конфигурации см. в разделе Системные переменные Galera Cluster.