Обновление минорной версии MariaDB

Обновление СУБД одна из наиболее распространенных задач администратора баз данных. С чего стоит начать, и с каким процессом действий предстоит столкнуться, расскажет наш технический специалист Владислав Лоскутов. Итак, существует множество причин обновления:

• Проблемы и ошибки
• Новые возможности
• Улучшения производительности (время отклика и масштабируемость)
• Требования приложения
• Скорое EOL
• Лучшая управляемость
• Исправление ошибок
• Проблемы с безопасностью

В данной статье описан процесс обновления версии MariaDB Galera Cluster с версии 10.4.13 на 10.4.19. В нашем случае, причин обновления было две: Первая причина: были замечены утечки памяти, которые отчетливо видны на графике ниже. Вторая причина: создание page-файлов при перезапуске сервиса. В первую очередь, мы просмотрели похожие случаи на официальном сайте вендора и нашли пару примеров, описывающих нашу проблему: https://jira.mariadb.org/browse/MDEV-22998 https://jira.mariadb.org/browse/MDEV-23060 В обоих ситуациях, MariaDB рекомендует обновление версии на 10.4.14 и 26.4.5 для Galera. Также мы думали над тем, чтобы изменить менеджер распределения оперативной памяти, например, jemalloc. Однако было принято решение протестировать обновленную версию MariaDB. Перейдем к непосредственному процессу обновления:

1.Сделать резервную копию файла конфигурации и БД.

Резервное копирование — это необходимый этап любого изменения. Прежде всего, данный процесс должен быть автоматизирован. Подробнее это действие опишем в отдельной статье. cp -v /etc/my.cnf.d/galera.cnf /etc/ my.cnf.d/galera.cnf_preupgrade ‘/etc/my.cnf.d/galera.cnf’ -> ‘/etc/my.cnf.d/galera.cnf_preupgrade’

2. Проверить список изменений версии на официальном сайте MariaDB на наличие устаревших параметров.

Проверку можно осуществить с помощью списка переменных на официальном сайте. Если переменная является устаревшей, то у нее будет соответствующее поле – Deprecated, с указанием неактуальной версии. Обнаружив такой параметр, его необходимо убрать из файла конфигурации. В ходе проверки мы не нашли устаревших параметров.

3. Обновить источник пакетов для новой версии.

В большинстве случаев, репозиторий yum уже сконфигурирован так, чтобы получить самую свежую версию. Однако лучше проверить и привести файл источника в следующий вид: cat /etc/yum.repos.d/mariadb.repo [mariadb-main] name = MariaDB Server baseurl = https://archive.mariadb.org/mariadb-10.4.19/yum/centos7-amd64/ gpgkey = file:///etc/pki/rpm-gpg/MariaDB-Server-GPG-KEY gpgcheck = 1 enabled = 1

4. Запустить три дополнительных терминала на каждом сервере и посмотреть журналы ошибок.

Этот шаг нужен для отслеживания состояния Galera-кластера. Поскольку выполнение какой-либо операции на одном узле, может привести к ошибкам на другом. tail-f /var/log/galera-error.log

5. Остановить нагрузку на кластер для сохранения номера последней совершенной транзакции (wsrep_last_committed).

В нашем случае, трафик шел только под одним пользователем и только удаленно. Зная это, мы ограничили удаленный доступ для этого пользователя во время операции, а также отключили активные соединения:
SELECT host, user FROM mysql.user WHERE user=’appuser’; +——+———+ | Host | User    | +——+———+ | %    | appuser | +——+———+ UPDATE mysql.user SET Host=’localhost’ WHERE User=’appuser’; SELECT host, user FROM mysql.user WHERE user=’appuser’; +————+———+ | Host      | User    | +————+———+ | localhost | appuser | +————+———+ FLUSH PRIVILEGES; SELECT concat(‘KILL ‘,id,’;’) FROM information_schema.processlist WHERE user=’appuser’ INTO OUTFILE’/tmp/terminate_appuser.txt’; SOURCE /tmp/terminate_appuser.txt; Процедура выполнялась на каждом сервере. Лучший способ сохранения номера последней совершенной транзакции — отключить трафик со стороны приложения. Именно этот метод мы использовали при обновлении версии на боевой среде. Во время операции трафик был перенаправлен на другую среду с такими же данными.

6. Выключить сервис MariaDB.

Непосредственное обновление версии начинается с этого этапа. Сначала отключаем сервис на одном узле и дожидаемся полной его остановки, проверяя журнал ошибок на наличие сообщений об успешном выключении: systemctl stop mariadb systemctl status mariadb После этого шага необходимо проверить синхронизацию двух других узлов:
SHOW GLOBAL STATUS WHERE VARIABLE_NAME IN (‘wsrep_cluster_size’, ‘wsrep_cluster_status’, ‘wsrep_evs_evict_list’, ‘wsrep_last_committed’, ‘wsrep_ready’, ‘wsrep_connected’, ‘wsrep_local_state_comment’); +—————————+————+ | Variable_name             | Value     | +—————————+————+ | wsrep_last_committed      | 383462123 | | wsrep_local_state_comment | Synced    | | wsrep_evs_evict_list      |           | | wsrep_cluster_size        | 2         | | wsrep_cluster_status      | Primary   | | wsrep_connected           | ON        | | wsrep_ready               | ON        | +—————————+————+
Сейчас кластер состоит из двух синхронизированных узлов, что является ожидаемым.

7. Обновить пакеты.

Текущий список установленных пакетов, относящихся к MariaDB:
{ yum list installed | grep Mar yum list installed | grep gale } MariaDB-backup.x86_64                10.4.13-1.el7.centos        @mariadb MariaDB-client.x86_64                   10.4.13-1.el7.centos        @mariadb MariaDB-common.x86_64             10.4.13-1.el7.centos        @mariadb MariaDB-compat.x86_64               10.4.13-1.el7.centos        @mariadb MariaDB-server.x86_64                  10.4.13-1.el7.centos         @mariadb MariaDB-shared.x86_64                 10.4.13-1.el7.centos         @mariadb galera-4.x86_64                         26.4.4-1.rhel7.el7.centos        @mariadb

Процесс обновления пакетов: sudo yum install MariaDB-server galera-4 MariaDB-client MariaDB-shared MariaDB-backup MariaDB-common MariaDB-compat
Новый список MariaDB-пакетов: { yum list installed | grep Mar yum list installed | grep gale } MariaDB-backup.x86_64                   10.4.19-1.el7.centos           @mariadb MariaDB-client.x86_64                   10.4.19-1.el7.centos           @mariadb MariaDB-common.x86_64                   10.4.19-1.el7.centos           @mariadb MariaDB-compat.x86_64                   10.4.19-1.el7.centos           @mariadb MariaDB-server.x86_64                   10.4.19-1.el7.centos           @mariadb MariaDB-shared.x86_64                   10.4.19-1.el7.centos           @mariadb galera-4.x86_64                         26.4.8-1.el7.centos            @mariadb

8. Запустить сервис MariaDB.

После установки новых пакетов, запускаем сервис. Важно убедиться в успешном запуске. systemctl start mariadb systemctl status mariadb После запуска проверим синхронизацию всего кластера:
SHOW GLOBAL STATUS WHERE VARIABLE_NAME IN (‘wsrep_cluster_size’, ‘wsrep_cluster_status’, ‘wsrep_evs_evict_list’, ‘wsrep_last_committed’, ‘wsrep_ready’, ‘wsrep_connected’,’wsrep_local_state_comment’); +—————————+————+ | Variable_name             | Value     | +—————————+————+ | wsrep_last_committed      | 383462126 | | wsrep_local_state_comment | Synced    | | wsrep_evs_evict_list      |           | | wsrep_cluster_size        | 3         | | wsrep_cluster_status      | Primary   | | wsrep_connected           | ON        | | wsrep_ready               | ON        | +—————————+————+

Наблюдаем полную синхронизацию всех трех узлов.

9.Следующих шаг — запустить обновление.

На этом этапе обновятся системные таблицы в БД до последней версии, и выполнится проверка всех таблиц (проверка их версий). mysql_upgrade -u root —skip-write-binlog

10. Перезапустить сервис MariaDB

Выполняем финальный перезапуск сервиса, проверяем успешность запуска и синхронизацию кластера:

systemctl restart mariadb systemctl status mariadb SHOW GLOBAL STATUS WHERE VARIABLE_NAME IN (‘wsrep_cluster_size’,’wsrep_cluster_status’, ‘wsrep_evs_evict_list’, ‘wsrep_last_committed’, ‘wsrep_ready’,’wsrep_connected’ ,’wsrep_local_state_comment’); +—————————+————+ | Variable_name             | Value     | +—————————+————+ | wsrep_last_committed      | 383542049 | | wsrep_local_state_comment | Synced    | | wsrep_evs_evict_list      |           | | wsrep_cluster_size        | 3         | | wsrep_cluster_status      | Primary   | | wsrep_connected           | ON        | | wsrep_ready               | ON        | +—————————+————+ { mysql -uroot -e «SELECT VERSION();» mysql -uroot -e «SHOW GLOBAL STATUS LIKE ‘wsrep_provider_version’;» } +———————+ | VERSION()           | +———————+ | 10.4.19-MariaDB-log | +———————+

+————————+——————+ | Variable_name          | Value            | +————————+——————+ | wsrep_provider_version | 26.4.8(r902dd26) | +————————+——————+

11. Возвращаем нагрузку.

Вернем возможность удаленного доступа для пользователя приложения:
SELECT host,user FROM mysql.user WHERE user=’appuser’; +————+———+ | Host      | User    | +————+———+ | localhost | appuser | +————+———+ UPDATE mysql.user SET Host=’%’ WHERE User=’appuser’; SELECT host,user FROM mysql.user WHERE user=’appuser’; +——+———+ | Host | User    | +——+———+ | %    | appuser | +——+———+ FLUSH PRIVILEGES;
Подведем итог нашей работы: на выполнение всех операций мы потратили 45 минут, из них 15 минут на сервер. Объем данных составляет 350 ГБ. Версия Linux: CentOS Linux release 7.4.1708 (Core). В результате, мы избавились от утечек памяти и проблемы с page-файлами: Обновление версии любой СУБД является трудоемким и кропотливым процессом, требующим внимания к деталям, а также, опыта работы в данной сфере. В арсенале DBI собраны лучшие практики по обновлению, миграции и обслуживанию практически любых баз данных. На примере этой статьи можно наблюдать как тщательно мы прорабатываем алгоритм этого многоступенчатого процесса: от проверки журналов сервиса, до наличия информации у вендора.