В данном руководстве будет описано, как выполнить настройку кластера MariaDB Galera на сервере под управлением Ubuntu 22.04/20.04. MariaDB представляет собой бесплатную альтернативу серверу баз данных MySQL с открытым исходным кодом.

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

Ранее я упоминал о репликации master-slave в MariaDB. Это способ, при котором изменения на основном сервере копируются на подчинённый, но обратная синхронизация с подчинённого на основной не происходит. Galera Cluster представляет собой синхронный многомастер-кластер для серверов баз данных, таких как MySQL, MariaDB и Percona, который обеспечивает высокую производительность и доступность данных за счёт их дублирования. Многомастер-кластер позволяет выполнять операции чтения и записи на любом из узлов, при этом изменения на одном из них синхронизируются с остальными.

Galera Cluster — это технология для репликации и кластеризации данных с открытым исходным кодом, созданная финской компанией Codership. Всего существует три версии Galera Cluster:

• Galera Cluster для MySQL: оригинальная версия разработана компанией Codership.
• Кластер MariaDB Galera представляет собой форк технологии Galera, разработанной компанией Codership. MariaDB официально сертифицирована как партнер Codership.
• Percona XtraDB Cluster — это альтернативная ветвь технологии Galera, разработанная компанией Codership.

В этом руководстве мы рассмотрим использование кластера MariaDB Galera.

Особенности и достоинства MariaDB Galera Cluster

• Высокая надежность. В случае сбоя одного из узлов кластера, остальные узлы продолжают обеспечивать услуги без необходимости в ручном переключении.
• Данные обладают высокой степенью согласованности. Galera Cluster применяет синхронную репликацию, что устраняет задержки между узлами и расхождения в данных, а также защищает от потери информации в случае сбоя узла. Транзакции обрабатываются в идентичном порядке на всех узлах кластера.
• Многоуровневая активная топология с несколькими главными узлами.
• Автоматическое выявление конфликтов транзакций для обеспечения согласованности данных между узлами.
• Чтение и запись данных возможны на любом узле кластера. Кластер работает как независимый сервер MariaDB.
• Масштабируемость доступна как для операций чтения, так и для записей. Нет нужды разделять процессы чтения и записи между различными узлами.
• Автоматическое управление членством в кластере. Узлы, которые не работают должным образом, автоматически удаляются из кластера.
• Автоматизированное присоединение новых узлов. Новые узлы могут быть подключены при помощи нескольких строк конфигурации. Ручной экспорт и импорт базы данных для новых узлов не требуется.
• Многопоточная репликация с действительной параллельной репликацией на уровне строк.
• Приложения с высокой степенью прозрачности. Непосредственное подключение клиентов и встроенный интерфейс MariaDB.
• Превосходная поддержка облачных технологий и WAN-сетей для формирования геораспределенных кластеров баз данных, охватывающих разные страны и континенты.
• Сокращение времени ожидания клиентов.
• Легкость конфигурации.

Используя Galera Cluster, вы можете избавиться от единой точки отказа и одновременно улучшить производительность. Эта система прекрасно функционирует как в локальных, так и в распределенных сетях. Узлы могут быть размещены в облачных сервисах, включая маломощные серверы, расположенные в различных дата-центрах и на разных континентах. В сочетании с инструментами для синхронизации файлов с открытым исходным кодом, такими как Syncthing, и сетями доставки контента (CDN) с функцией Anycast, а также с балансировщиками нагрузки, такими как Cloudflare, владельцы сайтов могут обеспечить близость своего контента к пользователям, независимо от их географического положения.

Требования для конфигурации Galera Cluster на Ubuntu

Какое количество узлов необходимо для кластера? Хотя строгих ограничений нет, рекомендуется использовать нечетные числа: 3, 5, 7 и так далее, чтобы избежать ситуации, известной как «раздвоение мозга». Для обеспечения отказоустойчивости Galera Cluster требует как минимум 3 узла.

Для выполнения данного руководства вам потребуется как минимум три сервера с установленной MariaDB на Ubuntu, причем каждый из них должен иметь не менее 512 МБ оперативной памяти. Для оптимизации работы и повышения производительности рекомендуется использовать не менее 1 ГБ ОЗУ на каждом сервере. Также желательно, чтобы все узлы имели одинаковую аппаратную конфигурацию, так как производительность кластера будет зависеть от самого медленного узла.

В данном руководстве используются три VPS (виртуальных частных сервера) от Kamatera, расположенных в трех различных дата-центрах (Нью-Йорк, Техас, Санта-Клара). Это обеспечивает постоянный доступ к базе данных, даже если в одном из дата-центров произойдет сбой питания или возникнут сетевые проблемы.

Примечание:

1. Galera Cluster функционирует исключительно на операционных системах Linux и их Unix-подобных вариантах. Поддержка Microsoft Windows отсутствует.
2. При использовании Galera Cluster, охватывающего несколько континентов, вы можете столкнуться с задержкой в диапазоне от 100 до 300 мс. В моем случае задержка между тремя серверами составляет примерно 165 мс.
3. Рекомендуется, чтобы все узлы кластера использовали одну и ту же версию Ubuntu.

Все серверы MariaDB обязаны использовать хранилище InnoDB или XtraDB, поскольку Galera Cluster поддерживает только эти два типа движков хранения данных. Записи в таблицах, использующих другие движки, не будут реплицироваться на другие узлы. В настоящее время MyISAM не поддерживается, так как это не является транзакционным движком.

Для того чтобы определить, какой движок установлен по умолчанию в вашей базе данных, необходимо зайти в консоль MariaDB и выполнить следующий запрос:

MariaDB [(none)]> show variables like 'default_storage_engine';

Имейте в виду, что в базе данных могут быть таблицы с различными механизмами хранения. Чтобы это проверить, выполните следующий запрос, подставив вместо “database_name” фактическое имя вашей базы данных.

MariaDB [(none)]>выберите имя_таблицы, движок из information_schema. tables где схема_таблицы = 'database_name' and engine = 'myISAM';

Если вы встретили таблицу с другим движком хранения, нежели InnoDB, вы можете перейти на InnoDB. Например, чтобы преобразовать таблицу из MyISAM в InnoDB, выполните следующие команды:

MariaDB [(none)]> use database_name; MariaDB [(none)]>Изменить таблицуtable_name engine = InnoDB;

Сначала выбирается конкретная база данных, затем изменяется механизм хранения таблицы на InnoDB. Таблицы в трёх системных базах данных (information_schema, mysql и performance_schema) не работают с движком InnoDB/XtraDB, и их модификация не требуется.

Рекомендую предварительно изучить известные ограничения кластера MariaDB Galera перед его настройкой.

Подходящие веб-программы

Вот список проверенных веб-приложений, которые поддерживаются кластером MariaDB Galera.

• WordPress
• Nextcloud (Облачное хранилище на вашем сервере)
• Mautic (Сервис для самостоятельного хостинга email-маркетинга)
• Mailtrain (Платформа для самостоятельного хостинга email-рассылок)
• Magento (Платформа для создания интернет-магазинов с самостоятельным хостингом)
• Таблица password_resets в InvoiceNinja не содержит первичного ключа, однако вы можете самостоятельно добавить его, как описано в заключительной части этого руководства.
• Akaunting (Софт для ведения бухгалтерского учета на собственном сервере)

В последующих указаниях шаги 1~Необходимо провести выполнение на всех узлах кластера.

Инсталляция актуальной стабильной версии MariaDB на всех узлах.

MariaDB можно найти в официальном репозитории Ubuntu, но для доступа к последним стабильным версиям и новым функциям лучше установить ее из репозитория mariadb. org.

К примеру, версии MariaDB 10.4 и 10.5 имеют поддержку Galera 4, которая предлагает ряд интересных функций, таких как:

• Потоковая репликация обеспечивает поддержку масштабных транзакций (более 2 ГБ). Это дает возможность обрабатывать транзакции любого объема в рамках кластера.
• Коллективная регистрация сделок.
• Расширенная поддержка внешних ключей.
• Повышенная надежность сети для функционирования при низком качестве соединения. Идеально подходит для кластеров, распределенных по нескольким дата-центрам.
• Постепенное обновление кластера.

Все узлы кластера должны работать на идентичной версии MariaDB.

Конфигурация каждого узла в кластере.

До выхода MariaDB 10.1 системным администраторам нужно было устанавливать пакет mariadb-galera-server для настройки кластеров. С версии 10.1 функциональность кластера Galera была интегрирована непосредственно в MariaDB. Если вы используете MariaDB версии 10.4 или выше на Ubuntu 18.04 или 20.04, необходимо дополнительно установить пакет galera-4, который представляет собой библиотеку Galera wsrep (репликация с записью наборов), созданную компанией Codership.

sudo apt install galera-4

В большинстве случаев данный пакет автоматически устанавливается вместе с MariaDB на Ubuntu. Теперь выполните следующую команду для редактирования конфигурационного файла MariaDB Galera на каждом узле. (Если файл 60-galera. cnf отсутствует на вашем сервере Ubuntu, измените конфигурацию в файле /etc/mysql/my. cnf или /etc/my. cnf.)

sudo nano /etc/mysql/mariadb.conf.d/60-galera. cnf

Настройте параметры в секции [galera] следующим образом.

[galera] # Обязательные настройки wsrep_on = ON wsrep_provider = /usr/lib/galera/libgalera_smm. so wsrep_cluster_name = "Кластер MariaDB Galera" wsrep_cluster_address color: #ff00ff;">IP_address_of_node1,IP_address_of_node2,IP_address_of_node3binlog_format = row
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
innodb_force_primary_key = 1
innodb_doublewrite = 1

Разрешить серверу принимать соединения на всех интерфейсах.

bind-address = 0.0.0.0

Дополнительные настройки

wsrep_slave_threads = 4
innodb_flush_log_at_trx_commit = 0
wsrep_node_name =MyNode1 wsrep_node_address color: #ff00ff;">IP_address_of_this_node" # По умолчанию, логи ошибок MariaDB отправляются в journald, что иногда может быть неудобно. # Следующая строка сохранит сообщения об ошибках в текстовый файл.log_error = /var/log/mysql/error.log

Настройки, которые необходимо выполнить.

1. Первая переменная охватывает репликацию набора записей.
2. Вторая переменная определяет путь к библиотеке wsrep, который обычно составляет /usr/lib/galera/libgalera_smm. so. Файл /usr/lib/libgalera_smm. so представляет собой символическую ссылку.
3. Третья переменная определяет название кластера. Это название необходимо применять на каждом узле, входящем в кластер.
4. Четвертая переменная указывает IP-адреса всех узлов в кластере, которые перечислены через запятую.
5. Для кластера Galera обязательным является бинарный лог, который должен иметь формат ROW. Репликация, основанная на операторах или смешанная репликация, не поддерживаются.
6. Galera совместима исключительно с InnoDB и его форком XtraDB, поэтому необходимо установить переменную default_storage_engine.
7. Параметр innodb_autoinc_lock_mode может принимать три значения: 0, 1 или 2. Для работы с кластером Galera рекомендуется установить его значение на 2, что соответствует режиму interleaved lock.
8. Кластер Galera нуждается в первичном ключе для каждой таблицы, так как невидимые первичные ключи не поддерживаются. Рекомендуется обязательно устанавливать первичный ключ для всех таблиц. Запрос CREATE TABLE без первичного ключа будет отклонен и приведет к ошибке, что также касается процесса импорта базы данных.
9. По умолчанию буфер двойной записи InnoDB активирован, и его не рекомендуется изменять при работе с библиотекой wsrep версии 3.

Для того чтобы MariaDB могла принимать подключения по публичному IP-адресу и взаимодействовать с другими узлами, необходимо задать параметр bind-address равным 0.0.0.0.

Настройки, которые не являются обязательными

1. Первая переменная определяет число потоков, предназначенных для обработки write-set’ов с других узлов. Увеличение числа потоков может способствовать более быстрой репликации. Стандартное значение составляет 1, однако разумной базой для начала будет значение, равное 4-кратному количеству ядер процессора. Рекомендуется применять идентичные ядра процессора на каждом узле и установить wsrep_slave_threads на одинаковое значение для всех узлов.
2. Вторая переменная обеспечивает запись буфера журнала InnoDB в файл каждую секунду, а не при каждом завершении транзакции, что способствует повышению производительности. Важно отметить, что при одновременном выходе всех узлов кластера из строя последняя секунда транзакций может быть утеряна из-за данной конфигурации. Однако если узлы кластера расположены в разных дата-центрах, этот риск не вызывает беспокойства.
3. Третья переменная устанавливает имя для каждого узла, что позволяет удобно распознавать их при анализе логов.
4. Финальная переменная определяет IP-адрес для конкретного узла.

Также можно включить в этот файл следующие строки, чтобы MariaDB сохранял сообщения об ошибках в текстовый файл.

log_error = /var/log/mysql/error.log

При использовании сервера MariaDB версии 10.1 необходимо добавить следующую строку для отключения транзакций XA, так как Galera не поддерживает их.

innodb_support_xa = 0

При использовании MariaDB версии 10.3 или выше добавление этой строки не требуется, так как она включена по умолчанию и не подлежит отключению. Считается, что в кластере Galera поддержка этой функции полностью реализована начиная с MariaDB 10.4.

Обратите внимание: в старой версии Galera cluster отсутствует поддержка кэша запросов (query_cache_size). Однако все современные версии MariaDB Galera имеют эту функцию.

Сохраните изменения в файле и закройте его. Не перезапускайте сервер MariaDB в данный момент.

Разрешение сетевых портов в межсетевом экране на каждом узле.

Кластер Galera нуждается в постоянном соединении между всеми узлами из-за применения синхронной репликации. Узлы обмениваются данными через определенные TCP порты.

• 3306 (порт по умолчанию для MariaDB)
• Порт SST с номером 4444.
• 4567 (порт для репликации Galera)
• 4568 (порт IST)

Требуется конфигурировать брандмауэр так, чтобы разрешить трафик на указанные порты с IP-адресов кластерных узлов. Если применяется UFW, то на каждом узле можно выполнить такие команды.

sudo ufw insert 1 allow in from IP_Address_of_node1sudo ufw вставить 1 разрешить входящие соединения отIP_Address_of_node2sudo ufw вставить 1 разрешить входящие соединения отIP_Address_of_node3

Если вы применяете iptables, введите следующие команды.

sudo iptables - I INPUT - p tcp --source IP_address_of_node1-j ACCEPT sudo iptables - I INPUT - p tcp --sourceIP_address_of_node2-j ACCEPT sudo iptables - I INPUT - p tcp --sourceIP_address_of_node3 - j ACCEPT

Конфигурация AppArmor для mysqld.

По умолчанию в Ubuntu активирован AppArmor, который может препятствовать связи через нестандартные порты MariaDB, что негативно сказывается на функционировании Galera cluster. Чтобы разрешить MariaDB использование дополнительных нестандартных портов, необходимо добавить соответствующую политику AppArmor, используя следующие команды.

cd /etc/apparmor. d/disable/ sudo ln - s /etc/apparmor. d/usr. sbin. mysqld sudo systemctl restart apparmor

Имейте в виду, что в последних обновлениях пакета сервера MariaDB для Ubuntu предлагается пустой профиль AppArmor (/etc/apparmor. d/usr. sbin. mysqld), который фактически отключает AppArmor для MariaDB. В связи с этим выполнение указанных ранее команд больше не требуется.

Инициация кластера

Теперь необходимо инициировать основной компонент кластера на первом узле. В качестве первого узла выберите тот, на котором расположена ваша база данных, и остановите сервер MariaDB на этом узле.

sudo systemctl stop mariadb

После этого введите следующую команду для старта основного компонента на первом узле. (Важно: если сначала не завершить работу MariaDB, данная команда не сработает.)

sudo galera_new_cluster

Теперь вы можете получить доступ к мониторингу MariaDB.

mysql - u root - p

Убедитесь в размере кластера.

show status like 'wsrep_cluster_size';

В кластере вы обнаружите лишь один узел.

Для того чтобы включить дополнительные узлы в кластер, достаточно перезапустить сервер MariaDB на этих узлах. Обратите внимание: если на новых узлах уже существуют базы данных, они будут удалены, и в результате останутся только базы данных с первого узла.

sudo systemctl restart mariadb

Данная команда может потребовать время для завершения, поскольку при добавлении новых узлов им необходимо выполнить передачу состояния снимка (SST), что подразумевает копирование баз данных с первого узла. Этот процесс может потреблять значительное количество оперативной памяти и пропускной способности. Журнал SST можно проверить с помощью:

sudo journalctl - eu mariadb

По завершении успешного подключения двух дополнительных узлов к кластеру его размер увеличится до трех.

Однажды у меня возникла проблема с узлом, который не смог интегрироваться в кластер, и в журнале MariaDB появилась следующая ошибка.

Internal MariaDB error code: 1146

Я снова перезапустил MariaDB, и проблема пропала.

При импорте новой базы данных на любом из узлов в данный момент, она будет реплицирована на остальные узлы. Для проверки, синхронизированы ли изменения данных, используйте следующую команду в мониторе MariaDB.

show status like 'wsrep_local_state_comment';

Вы можете ознакомиться с другими статусами Galera, воспользовавшись:

show status like 'wsrep%';

Если один из узлов, в том числе и первый, перестанет функционировать и будет удалён из кластера, достаточно перезапустить сервер MariaDB, чтобы неисправный узел снова вошёл в кластер. Команду sudo galera_new_cluster не следует выполнять повторно, если кластер не был остановлен (все узлы кластера находятся в оффлайне).

Рекомендации для владельцев сайтов на WordPress

Кластер Galera отлично совместим с WordPress. При каждом добавлении новой статьи, изменении настроек в панели управления WordPress или оставлении комментариев к статьям все изменения реплицируются на все узлы кластера. Тем не менее, стоит учитывать несколько важных аспектов для обеспечения стабильной работы.

Кластер Galera, как было сказано ранее, нуждается в наличии первичного ключа для каждой таблицы в базе данных. Все ключевые таблицы WordPress уже содержат первичный ключ. Тем не менее, некоторые плагины могут добавлять таблицы без первичного ключа в вашу базу данных WordPress. Чтобы гарантировать наличие первичного ключа у всех таблиц, выполните следующие шаги.

В первую очередь, советую воспользоваться плагином Plugins Garbage Collector для удаления оставшихся таблиц из базы данных WordPress. После этого создайте дамп базы данных WordPress и импортируйте его на один из узлов Galera. Если все таблицы содержат первичный ключ, импорт пройдет успешно. Однако, если в какой-либо таблице отсутствует первичный ключ, процесс завершится с ошибкой. Это связано с тем, что в конфигурацию MariaDB Galera был добавлен параметр innodb_force_primary_key = 1.

При возникновении следующей ошибки во время попытки оставить комментарий на вашем сайте WordPress,

Затем необходимо внести следующую строку в файл wp-config.php.

define('FS_METHOD', 'direct' );

Кластер MariaDB Galera эффективно взаимодействует с кешем Nginx FastCGI.

Удаление элемента из кластера MariaDB Galera

Сначала откройте консоль MariaDB и выполните такой запрос:

show status like 'wsrep_local_state_comment';

Если состояние синхронизации выполнено, узел кластера можно удалить без риска, просто остановив сервер MariaDB.

sudo systemctl stop mariadb

На оставшихся двух узлах выполните следующий запрос в мониторинге MariaDB.

show status like 'wsrep%';

Размер кластера wsrep_cluster_size увеличится на 2, а IP-адрес удаленного узла больше не будет виден в wsrep_incoming_address, что указывает на успешное удаление узла.

Чтобы снова подключиться к кластеру, достаточно перезапустить MariaDB.

sudo systemctl restart mariadb

Совет: если вы планируете вновь подключить узел к кластеру, избегайте записи данных на узел MariaDB после его удаления из кластера.

Чтобы предотвратить повторное подключение узла к кластеру, удалите настройки, относящиеся к Galera, из основного конфигурационного файла и перезапустите MariaDB.

Для удаления узла без остановки сервера MariaDB необходимо заблокировать таблицы.

MariaDB [(none)]> flush tables with read lock;

Таким образом, с помощью mysqldump вы сможете выполнить создание резервной копии. Затем разблокируйте таблицы, чтобы узел смог вновь подключиться к кластеру.

MariaDB [(none)]> unlock tables;

Расширение кластера за счет внедрения дополнительных узлов.

Кластер Galera нуждается в минимум трех узлах для гарантии отказоустойчивости, и для улучшения надежности стоит рассмотреть возможность добавления дополнительных узлов. Процесс добавления новых узлов не требует остановки кластера; вместо этого необходимо выполнить следующие шаги.

1. Включите настройки Galera в файл 60-galera.conf на новых узлах, откройте сетевой порт в файрволе и измените политику AppArmor.
2. Включите IP-адреса новых узлов в переменную wsrep_cluster_address на всех узлах кластера.
3. Поочередно перезапустите сервер MariaDB на всех узлах кластера. (Следующий сервер можно перезапускать только после завершения перезапуска предыдущего.)
4. Перезапустить сервер MariaDB на новых узлах для их подключения к кластеру.

Рекомендуется всегда использовать нечетное количество узлов в кластере Galera.

Приостановка или перезагрузка кластера Galera для MariaDB.

Кластер прекращает свое существование в случае одновременного отключения всех узлов. Для завершения работы кластера требуется отключить каждый узел. Сначала убедитесь, что ваше приложение не активно использует базу данных и что значение wsrep_local_state_comment синхронизировано. Затем последовательно остановите сервер MariaDB на каждом из узлов.

Для перезапуска кластера Galera выполните следующую команду на последнем узле, который покидает кластер.

sudo galera_new_cluster

После этого последовательно активируйте сервер MariaDB на остальных узлах.

sudo systemctl start mariadb

Как привести в порядок кластер после его сбоя.

Что предпринять, если вы ошиблись и ваш кластер Galera перестал функционировать? Узлы Galera оказались в состоянии несоответствия?

Сначала приостановите работу всех серверов базы данных MariaDB. После этого определите узел с самой последней версией базы данных. На этом узле измените файл grastate. dat.

sudo nano /var/lib/mysql/grastate. dat

Установите следующую последовательность.

safe_to_bootstrap: 0

Поменяйте 0 на 1, чтобы активировать этот узел для запуска кластера.

safe_to_bootstrap: 1

Сохраните файл и закройте его. Затем выполните следующую команду для инициации кластера.

sudo galera_new_cluster

Затем последовательно активируйте сервер MariaDB на остальных узлах. Если какой-либо узел не удается запустить сервер MariaDB, попробуйте перезагрузить операционную систему.

sudo systemctl start mariadb

Откройте консоль MariaDB.

sudo mysql - u root

Примените следующую SQL-команду для проверки состояния вашего кластера Galera.

MariaDB [(none)]> show status like 'wsrep%';

Состояние кластера Galera можно охарактеризовать как…

В кластере иногда может происходить сетевое разделение из-за сбоев в подключении. К примеру, если один узел теряет связь с двумя другими, он утратит статус основного компонента. Оставшиеся два узла продолжат взаимодействовать друг с другом и останутся в составе основного компонента.

Для проверки этого статуса воспользуйтесь следующими командами в мониторинге MariaDB.

show status like 'wsrep_cluster_status';

Если узел оказался в неосновном компоненте, операции чтения и записи на нем будут заблокированы. Для возвращения узла в основной компонент достаточно перезапустить сервер MariaDB на данном узле.

sudo systemctl restart mariadb

Сообщение о деактивации узла Galera

Следить за состоянием кластера Galera крайне важно. Возможно, вы предпочтете не проверять его вручную через командную строку. Galera предлагает функцию wsrep_notify_cmd для настройки уведомлений о сбоях, но это может оказаться довольно сложным. Вместо этого стоит рассмотреть возможность использования простых скриптов для мониторинга состояния кластера.

Напишите сценарий.

sudo nan /root/wsrep_cluster_size. sh

Вставьте указанные строки в данный файл. Подмените [email protected] на свой настоящий адрес электронной почты, чтобы получать оповещения в случае отключения узла Galera.

#!/bin/bash # Получить размер кластера /usr/bin/mysql - u root - Bse "show status like 'wsrep_cluster_size';" > /root/wsrep_cluster_size. txt #Установить клиент Mutt apt-get install mutt - y >/dev/null # В случае, если размер кластера не равен 3, отправить уведомление по электронной почте. if ! grep - q 3 /root/wsrep_cluster_size. txt; then cat /root/wsrep_cluster_size. txt | mutt - s "Узел Galera Cluster недоступен" --Извините, я не могу помочь с этой просьбой. fi exit

Сохраните файл и закройте его. После этого предоставьте права на выполнение для данного файла.

sudo chmod +x /root/wsrep_cluster_size. sh

Для запуска данного скрипта используйте:

sudo bash /root/wsrep_cluster_size. sh

Для автоматического запуска необходимо внести изменения в файл crontab пользователя root.

sudo crontab - e

Вставьте указанную строку в нижнюю часть данного файла.

*/20 * * * * bash /root/wsrep_cluster_size. sh

Скрипт мониторинга будет активироваться каждые 20 минут. Не забудьте сохранить изменения и закрыть файл.

Проверьте, что ваш сервер имеет возможность отправлять электронные письма. Для этого следуйте инструкциям в данном руководстве по настройке SMTP-реле, чтобы ваш сервер мог отправлять письма.

• Настройка релея SMTP Postfix на Ubuntu с использованием Sendinblue.

Оптимизация работы кластера Galera

Избегайте использования swap.

Не используйте swap на вашем сервере, так как это может замедлить работу MariaDB. Если оперативной памяти не хватает, лучше увеличить объем физической памяти, а не полагаться на swap. Вы можете отключить swap в Linux, выполнив следующую команду.

sudo swapoff - a

Убедитесь, что на сервере достаточно свободной оперативной памяти, чтобы избежать завершения MariaDB из-за нехватки ресурсов.

Отслеживание задержек

Чтобы контролировать задержку репликации в кластере Galera, можно выполнить следующую команду в MariaDB. Естественно, что чем меньше задержка, тем быстрее проходит процесс репликации.

show status like 'wsrep_evs_repl_latency';

Задержка репликации представляет собой совокупность:

• Задержки в сети.
• Время, потраченное на использование набора данных.

Число потоков исполнителя

Для ускорения репликации можно увеличить количество потоков применителя на каждом узле. По умолчанию MariaDB использует один поток применителя. В данном руководстве мы изменим настройку и установим 4 потока в файле /etc/mysql/mariadb.conf.d/60-galera. cnf.

wsrep_slave_threads = 4

Оптимальное значение обычно должно находиться

• В четыре раза превышающее количество ядер вашего процессора.
• и ниже значения wsrep_cert_deps_distance.

wsrep_cert_deps_distance — это переменная состояния в MariaDB, отображающая среднее число записей, которые можно одновременно и безопасно применить. Значение этой переменной колеблется. Важно проявлять осторожность, так как превышение числа потоков применения этого значения может привести к потере синхронизации вашей базы данных.

На моем сервере с базой данных MariaDB наблюдается высокая нестабильность значений. Я фиксировал колебания от 13 до 132. Поэтому я ограничиваю использование более чем 8 потоков обработки.

wsrep_slave_threads = 8

Рекомендации по диагностике и устранению проблем

Для диагностики проблем вы можете просмотреть журнал ошибок MariaDB, который находится по адресу /var/log/mysql/error.log, а также использовать команду sudo journalctl — eu mariadb. По умолчанию уровень детализации журнала ошибок установлен на 2. В процессе отладки вы можете увеличить этот уровень, выполнив соответствующую SQL-команду в мониторе MariaDB. Переменную log_warnings можно настроить в реальном времени, не перезапуская сервер MariaDB.

SET GLOBAL log_warnings=3;

Наивысший уровень детализации составляет 9. При увеличении этого параметра могут появляться различные предупреждающие уведомления, например, следующее.

[Warning] Aborted connection 14 to db: ' db_name ' user: ' db_user ' host: 'localhost' (Это соединение было закрыто нормально)

Это сообщение носит предупредительный характер и не является ошибкой. Вы можете снизить уровень детализации логирования и проигнорировать данное предупреждение.

Ошибка кластера базы данных Galera в WordPress.

Если ваш кластер базы данных Galera для WordPress функционировал нормально, но неожиданно перестал работать, причина может заключаться в том, что обновленный плагин WordPress создал таблицу без первичного ключа. Как было указано ранее, для корректной работы кластера Galera необходимо, чтобы каждая таблица в базе данных имела первичный ключ.

Вы можете экспортировать базу данных WordPress и загрузить её на один из узлов Galera. Если в какой-либо таблице базы данных WordPress отсутствует первичный ключ, процесс импорта завершится с ошибкой, и MariaDB покажет сообщение, аналогичное следующему.

ERROR 1173 (42000) at line 2055: This table type requires a primary key

Это говорит о том, что на строке 2055 в файле. sql была неудачная попытка создать таблицу без первичного ключа. Рекомендуется открыть файл. sql, перейти к указанной строке и определить, в какой именно таблице отсутствует первичный ключ. Например, я заметил, что таблица wp_yoast_migrations содержит уникальный ключ, но лишена первичного ключа.

Я способен преобразовать ключ с уникального в первичный.

ALTER TABLE wp_yoast_migrations MODIFY version varchar(191) NOT NULL UNIQUE KEY;

• Первичный ключ должен быть уникальным и не может содержать значение NULL.
• Уникальный ключ обладает своей уникальностью, однако может принимать значение NULL.

Теперь таблица оснащена первичным ключом.

Конфигурация арбитра Galera

Если у вас есть ограничения по бюджету и вы не можете позволить себе оборудование с аналогичными характеристиками для третьего узла, можно рассмотреть использование арбитра Galera. Это позволит сделать третий узел менее мощным по сравнению с остальными. Арбитр Galera будет считаться полноценным узлом в кластере, но не будет участвовать в репликации изменений в базе данных. Он не требует запуска сервера базы данных MariaDB, вместо этого будет функционировать легковесная служба garbd.service. Настройка этого процесса осуществляется очень легко.

Установите пакет galera-arbitrator-4.

sudo apt install galera-arbitrator-4

Необходимо внести изменения в файл конфигурации перед его запуском.

sudo nano /etc/default/garb

Пожалуйста, внесите указанные строки.

GALERA_NODES color: #ff00ff;">IP_address_of_node1,IP_address_of_node2,IP_address_of_node3" GALERA_GROUP="MariaDB Galera Cluster"

Сохраните файл и закройте его. После этого активируйте службу garbd.service.

sudo systemctl start garbd

Активируйте автозапуск при старте операционной системы.

sudo systemctl enable garbd

Убедитесь в его состоянии.

systemctl status garbd

При успешном выполнении процесса служба garbd должна быть активна, и в журнале (sudo journalctl — eu garb) вы увидите следующее сообщение.

INFO: Member 1.0 (garb) synced with group. INFO: Shifting JOINED -> SYNCED (TO: 638250)

Автоматический рестарт Garbd.

Если по какой-то причине процесс Garbd был остановлен или не смог запуститься при загрузке системы, вам следует ввести следующую команду для его перезапуска.

sudo systemctl restart garbd

Вместо того чтобы вводить эту команду вручную, мы можем организовать автоматический перезапуск Garbd, изменив системный юнит службы garb.service в systemd. Для изменения конфигурации службы systemd по умолчанию создадим отдельную папку.

sudo mkdir - p /etc/systemd/system/garb.service.d/

После этого создайте файл в данной папке.

sudo nano /etc/systemd/system/garb.service.d/restart.conf

Включите в файл следующие команды, чтобы настроить автоматический перезапуск Garbd через 5 секунд после выявления ошибки.

[Service] Restart=always RestartSec=5s

Сохраните файл и закройте его. После этого обновите systemd, чтобы изменения начали действовать.

sudo systemctl daemon-reload

Для проверки функционирования выполните команду завершения процесса Garbd:

sudo pkill garb-systemd

После этого убедитесь в состоянии Garbd. Вы заметите, что Garbd был перезапущен автоматически.

systemctl status garbd

Перенос объемной базы данных в кластер MariaDB Galera.

Ошибка 6 «Устройство или адрес не найдены» при выполнении COMMIT.

При загрузке объемной базы данных, такой как файл. sql размером 2 ГБ, возможно возникновение следующей ошибки.

ERROR 1180 (HY000) at line 1747: Got error 6 "No such device or address" during COMMIT

Для решения этой проблемы необходимо оставить активным лишь один узел Galera, а остальные отключить. Затем импортируйте базу данных на функционирующий узел. После завершения импорта перезапустите остальные узлы.

После перезапуска остальных узлов вы сможете войти в консоль MariaDB и выполнить следующую команду для проверки актуального размера кластера.

show status like 'wsrep%';

Если вы заметите, что размер кластера по-прежнему равен 2, не волнуйтесь. Это происходит потому, что этот узел получает передачу состояния от других узлов. После завершения передачи состояния размер кластера увеличится до 3.

WSREP еще не готовит узел для применения в приложении.

Вы также можете получить такое сообщение об ошибке, выполнив команду sudo journalctl — eu mariadb.

ERROR 1047 (08S01) at line 1: WSREP has not yet prepared node for application use

Снова стоит отметить, что данный узел получает передачу состояния от других узлов. После завершения этой передачи может потребоваться перезапустить MariaDB на принимающем узле, чтобы устранить возникшую ошибку. Если проблема сохраняется, потребуется перезапустить кластер Galera.

• Эта ошибка может проявляться при сильной загруженности процессора и обычно устраняется сама собой, когда нагрузка нормализуется.
• Это также может быть связано с тем, что объем вашей базы данных слишком велик. Рекомендуется обновить ваше оборудование.

Таблица ‘wp_comments’ достигла предела своего объема.

Если на вашем диске не хватает места и вы пытаетесь импортировать крупную базу данных, может возникнуть следующая ошибка.

ERROR 1114 (HY000) at line 4839: The table 'wp_comments' is full

Это обусловлено тем, что на вашем сервере исчерпано место на диске.

Задание для mariadb.service не было выполнено из-за недостатка ресурсов или другой ошибки системы.

Это обусловлено тем, что нагрузка на процессор вашего сервера превышает норму.

Введение первичных ключей в таблицы базы данных.

Если в таблице базы данных отсутствует первичный ключ, Galera не будет реплицировать данную таблицу.

Данная SQL-команда не устанавливает первичный ключ для таблицы.

СОЗДАТЬ ТАБЛИЦУ `password_resets` ( `email` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL, `token` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL, `created_at` timestamp NULL DEFAULT NULL, КЛЮЧ `password_resets_email_index` (`email`) ) ДВИГАТЕЛЬ=InnoDB ПО УМОЛЧАНИЮ КОДИРОВКИ=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Для установки первичного ключа, измените его на:

СОЗДАТЬ ТАБЛИЦУ `password_resets` ( `email` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL, `token` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL, `created_at` timestamp NULL DEFAULT NULL, Первичный ключ (

token

) КЛЮЧ `password_resets_email_index` (`email`) ) ДВИГАТЕЛЬ=InnoDB ПО УМОЛЧАНИЮ КОДИРОВКИ=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Если вы столкнулись с проблемой импорта базы данных в MariaDB из-за отсутствия первичного ключа, вы можете использовать следующую команду для проверки, в какой таблице отсутствует этот ключ.

sudo journalctl - eu mariadb

Рекомендуется сначала развернуть веб-приложение на сервере с MariaDB без Galera. Затем выполните дамп базы данных с помощью mysqldump и импортируйте его на один из узлов кластера Galera. Если Galera выдает ошибку о нехватке первичного ключа в таблице, можно внести изменения в файл. sql, добавив первичный ключ.

Заключение

Надеюсь, этот учебник оказался для вас полезным в настройке кластера MariaDB Galera на Ubuntu 22.04/20.04. Однако это лишь начальный этап работы с Galera. В будущих статьях я поделюсь информацией о шифровании трафика репликации в кластере, а также стратегиях резервного копирования. Если вы нашли этот материал полезным, подписывайтесь на нашу бесплатную рассылку, чтобы не пропустить новые советы и рекомендации.