Обновление минорной версии 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 собраны лучшие практики по обновлению, миграции и обслуживанию практически любых баз данных. На примере этой статьи можно наблюдать как тщательно мы прорабатываем алгоритм этого многоступенчатого процесса: от проверки журналов сервиса, до наличия информации у вендора.

8 причин для миграции в облако

Бизнес пользователи по всему миру переходят от старых не мобильных решений к новой гибкой, масштабируемой, и гораздо более рентабельной облачной инфраструктуре.
Существует множество веских причин чтобы задуматься о миграции в облако, будь то снижение затрат на IT или ускорение процесса внедрения инноваций.
Но без опытных специалистов и продуманного плана процесс миграции может вызвать дополнительные трудности.

Основные 8 причин для миграции:

  • Снижение затрат на IT
  • Гибкость рабочих процессов
  • Повышение уровня безопасности
  • Решение проблем с устаревшим оборудованием
  • Консолидация дата центров
  • Предоставление возможности цифровой трансформации
  • Ускорение развития
  • Использование преимуществ новых технологий

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

Снижения затрат на IT

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

Гибкость рабочих процессов

Миграция в облако — это современное решение оптимизации бюджета.
Наличие быстрого доступа к 99% (большинству) необходимых IT ресурсов позволяет конкурировать на равных в активно меняющейся бизнес среде. Компании больше не требуется ждать недели или даже месяцы, для подключения и установки инфраструктурных компонентов — достаточно добавить необходимые ресурсы к вашей облачной системе, позволяя реализовать бизнес-идеи гораздо быстрее.

Повышение уровня безопасности

Безопасности всегда уделяется особое внимание. С миграцией в облако, компания может модернизировать IT инфраструктуру согласно самым современным практикам и максимально защитить свой бизнес от кибер-угроз.

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

Решение проблем с устаревшим оборудованием

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

Консолидация дата центров

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

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

Ускорение развития

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

Использование преимуществ новых технологий

Ну и, конечно, миграция в облако открывает бесчисленные возможности для внедрения новых современных технологий. Например, машинное обучение, искусственный интеллект, контейнерные технологии (Kubernetes).

Процесс миграции в облако

Получение максимальных преимуществ миграции в облако возможно при использовании всех возможностей оптимизации которое предоставляет облако. Как эксперты в облачных технологиях, мы понимаем все тонкости, с которыми компания сталкивается при миграции.
К счастью, один из лидеров рынка AWS предлагает программу миграции МАР, которая содержит 3 фазы:

1. Оценка готовности миграции (MRA)
2. Подготовка и планирование миграции (MRP)
3. Миграция

В 1й фазе важно ответить на следующие вопросы:

  • Возможно ли функционирование Вашего бизнеса в облаке?
  • Если нет, то что необходимо изменить?
  • Каков сценарий использования облака?
  • В чём Ваша выгода из вышеперечисленных пунктов?

После того, как Вы ответили на эти вопросы, требуется составить план (MRP) по миграции приложений и нагрузки, которые вы хотите перенести в облако. Во время планирования миграции вы сможете оптимизировать свой бизнес-процесс благодаря новым возможностям облачных технологий.

Миграция в AWS с DBI

За последние годы мы помогли нашим клиентам и партнёрам успешно мигрировать в AWS используя МАР подход.

Как это работает: Отдел DevOps. Навыки и технологии

Продолжаем нашу рубрику “Как это работает” рассказом DevOps-инженера Виктора Ефимова.

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

Итак, для начала разберём: что такое DevOps?

DevOps (Development Operation) – это набор методов для повышения эффективности процессов разработки (Development) и эксплуатации (Operation) программного обеспечения. Эффективность повышается за счет их непрерывной интеграции и активного взаимодействия между специалистами команды разработки, а также с помощью инструментов автоматизации.

На сегодняшний день сфера DevOps является одной из самых востребованных и быстроразвивающихся в IT — отрасли, поскольку многие компании начали внедрять DevOps — практики в свои циклы разработки, тестирования и релиза программного обеспечения. На протяжении всего жизненного цикла программного обеспечения DevOps-инженеры участвуют в автоматизации процессов подготовки, разработки и тестирования инфраструктуры, а также в последующей её эксплуатации и мониторинге.

Навыки и технологии, которыми должен владеть DevOps специалист

DevOps-инженер должен обладать знаниями из самых разных областей IT: программирование, работа с операционными системами, базами данных, системами сборки автоматизации и конфигураций. К ним добавляется умение работать с облачной инфраструктурой, системами оркестрации, мониторинга и т.д.

Текущий спектр технологий и инструментов, с которыми будет работать DevOps-инженер, зависит от конкретной компании и проектов, поэтому можем выделить следующие пункты, которые обязательны для DevOps-профессионала:

1) Основы компьютерных сетей

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

2) Операционные системы

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

Знать все возможности каждой версии, каждой системы невозможно, но хороший DevOps-специалист понимает общие принципы работы любой ОС.

3) Языки программирования

Необязательно знать языки программирования на очень высоком уровне, но в работе DevOps важно уметь ориентироваться в чужом коде и понимать хотя бы на минимальном уровне, как он работает. К тому же часто требуется написать скрипты для автоматизации или тестирования определенного процесса. Сегодня самыми популярными скриптовыми языками программирования являются Python, Go, Bash, Powershell.

4) Системы контроля версий

Система контроля версий — программное обеспечение, которое нужно для отслеживания изменений внутреннего кода программы; также она позволяет хранить несколько версий кода. Без системы контроля версий сейчас нельзя представить ни одну командную разработку любого ПО.

Сейчас систем контроля версий много и они отличаются набором характеристик, но на данный момент Git является самой популярной, этаким «золотым стандартом», который используется практически везде, поэтому имеет смысл изучать именно его.

5) Системы управления конфигурацией (например, Ansible)

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

Самыми популярными на сегодняшний день инструментами являются Ansible, Chef, Puppet, Saltstack и т.д.

6) CI/CD инструменты

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые помогают разработчикам чаще и надежнее развертывать изменения программного обеспечения. CI/CD позволяет упростить процесс разработки, снизить трудоемкость работы и сделать её более предсказуемой за счёт раннего обнаружения и устранения ошибок и конфликтов.

Самыми популярными инструментами для реализации CI/CD концепции являются GitLab, Jenkins, TeamCity, Bamboo и т.д.

7) Системы оркестрации и микросервисы

Для доставки и развертывания современных приложений используют контейнеры и микросервисы. Данный подход позволяет разбить монолитное приложение на множество маленьких частей, что позволяет разрабатывать и обновлять их независимо друг от друга. Для управления контейнерами используют системы оркестрации, знание которых в настоящее время необходимо хорошему DevOps — инженеру. Одной из популярных систем является Kubernetes, но ещё есть Openshift, Docker Swarm и т.п.

8) Infrastructure as Code

Модель «Инфраструктура как код» (IaC) является неотъемлемой частью работы DevOps-инженеров. С помощью IaC описывается гибкая, масштабируемая архитектура, которая, при желании, может быть легко изменена, дополнена либо уничтожена через код. Также можно быстро автоматизировать развертывание нового проекта и избавиться от зависимости, железа или провайдеров. На данный момент самым популярным средством IaC является Terraform.

9) Cloud platform (AWS, GCP, AZURE)

Сейчас бизнес уходит от развертывания своей инфраструктуры в собственных дата-центрах в пользу создания окружения у облачных провайдеров. Облачные платформы позволяют уменьшить затраты на инфраструктуру, легко масштабировать ресурсы, использовать для разработки собственные PaaS/Saas-решения и т.п. Поэтому DevOps-инженеру необходимо знать решение как минимум одного облачного провайдера. На сегодняшний день самыми известными являются Amazon Web Services, Azure, GCP, в России — Yandex Cloud.

10) Английский язык

Данный пункт всё-таки можно отнести к soft skills, но знание английского довольно важно, поскольку почти вся документация и обучающие материалы по стэку DevOps предоставлена исключительно на английском языке. И, если речь идет об иностранном рынке (иностранных клиентах или работодателе), то знание английского обязательно. Кроме этого, будет нелишним иметь навыки делового общения и переписки на английском.

Если вы хотите попробовать свои силы в таком суперперспективном направлении как DevOps, то мы будем рады увидеть вас в нашей команде! Просто отправьте резюме на hr@dbi.ru.