Миграция с MariaDB 10.1 на MariaDB 10.2 с использованием кластера Galera

Начиная с MariaDB 10.1, кластер Galera поставляется с MariaDB Server. Обновление узла кластера Galera очень похоже на обновление сервера с MariaDB 10.1 на MariaDB 10.2. Более подробную информацию об этом процессе, а также о несовместимостях между версиями, см. в руководстве по обновлению.

Поэтапное обновление

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

Сначала, перед началом:

1. Сначала ознакомьтесь с руководством по обновлению с MariaDB 10.1 на MariaDB 10.2, чтобы увидеть, что изменилось между основными версиями.
   1. Проверьте, были ли изменены или удалены системные переменные или параметры. Убедитесь, что конфигурация вашего сервера совместима с новой версией MariaDB перед обновлением.
   2. Проверьте, не изменилась ли репликация в новой версии MariaDB таким образом, что это может вызвать проблемы, когда кластер содержит обновленные и не обновленные узлы.
   3. Проверьте, не добавлены ли новые функции в новую версию MariaDB. Если новая функция в новой версии MariaDB не может быть воспроизведена в старой версии MariaDB, не используйте эту функцию, пока все узлы кластера не будут обновлены до новой версии MariaDB.
2. Далее убедитесь, что версии Galera совместимы.
   1. Если вы обновляетесь с последней версии MariaDB 10.1 на MariaDB 10.2, версии будут совместимы. И MariaDB 10.1, и MariaDB 10.2 используют Galera 3 (т.е. версии поставщика Galera wsrep 25.3.x), поэтому они должны быть совместимы.
   2. См. Что такое MariaDB Galera Cluster?: Версии Galera wsrep provider для получения информации о том, какие версии MariaDB используют какие версии Galera wsrep provider.
3. В идеале, вы хотите иметь достаточно большой gcache, чтобы избежать передачи моментального снимка состояния во время поэтапного обновления. Размер gcache можно настроить, задав gcache.size Например:
   wsrep_provider_options="gcache.size=2G"

Затем для каждого узла выполните следующие действия:

1. Измените конфигурацию репозитория, чтобы система менеджер пакетов установила MariaDB 10.2. Например,
   • В дистрибутивах Linux, таких как Debian, Ubuntu и аналогичных, см. Обновление репозитория MariaDB APT до новой основной версии для получения дополнительной информации.
   • В дистрибутивах Linux, таких как RHEL, CentOS, Fedora и аналогичных, см. Обновление репозитория MariaDB YUM до новой основной версии для получения дополнительной информации.
   • В дистрибутивах Linux, таких как SLES, OpenSUSE и аналогичных, см. Обновление репозитория MariaDB ZYpp до новой основной версии для получения дополнительной информации.
2. Если вы используете прокси балансировки нагрузки, такой как MaxScale или HAProxy, убедитесь, что сервер исключен из пула, чтобы он не принимал новых подключений.
3. Установите innodb_fast_shutdown в 0. Его можно динамически изменить с помощью SET GLOBAL. Например:
   SET GLOBAL innodb_fast_shutdown=0;
   • Этот шаг не требуется при обновлении до MariaDB 10.2.5 или более поздней версии. Пропуск его может значительно ускорить процесс обновления. См. MDEV-12289 для получения дополнительной информации.
4. Остановите MariaDB.
5. Удалите старую версию MariaDB и поставщика Galera wsrep.
   • В дистрибутивах Linux, таких как Debian, Ubuntu и аналогичных, выполните следующее:
     sudo apt-get remove mariadb-server galera
   • В дистрибутивах Linux, таких как RHEL, CentOS, Fedora и аналогичных, выполните следующее:
     sudo yum remove MariaDB-server galera
   • В дистрибутивах Linux, таких как SLES, OpenSUSE и аналогичных, выполните следующее:
     sudo zypper remove MariaDB-server galera
6. Установите новую версию MariaDB и поставщика Galera wsrep.
   • В дистрибутивах Linux, таких как Debian, Ubuntu и аналогичных, см. Установка пакетов MariaDB с помощью APT для получения дополнительной информации.
   • В дистрибутивах Linux, таких как RHEL, CentOS, Fedora и аналогичных, см. Установка пакетов MariaDB с помощью YUM для получения дополнительной информации.
   • В дистрибутивах Linux, таких как SLES, OpenSUSE и аналогичных, см. Установка пакетов MariaDB с помощью ZYpp для получения дополнительной информации.
7. Внесите необходимые изменения в параметры конфигурации в файлах параметров, такие как my.cnf. Это включает удаление любых системных переменных или параметров, которые больше не поддерживаются.
   • Для беспроблемной работы кластера Galera в MariaDB 10.2 системная переменная innodb_lock_schedule_algorithm должна быть установлена в FCFS. В MariaDB 10.2.12 и более поздних версиях эта системная переменная автоматически устанавливается в это значение при включенном кластере Galera. В MariaDB 10.2.11 и более ранних версиях эта системная переменная должна быть установлена вручную. См. MDEV-12837 для получения дополнительной информации.
8. В дистрибутивах Linux, использующих systemd, вам может потребоваться увеличить таймаут запуска службы, так как значение по умолчанию 90 секунд может быть недостаточным. См. Systemd: Настройка таймаута службы Systemd для получения дополнительной информации.
9. Запустите MariaDB.
10. Выполните mysql_upgrade с параметром --skip-write-binlog.
    • mysql_upgrade выполняет две вещи:
      1. Гарантирует, что системные таблицы в базе данных mysql полностью совместимы с новой версией.
      2. Производит очень быструю проверку всех таблиц и помечает их как совместимые с новой версией MariaDB.

После завершения этого процесса для одного узла переходите к следующему узлу.

Дополнительные сведения

Проверка статуса передачи состояния

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

Передачи состояния, обеспечивающие доступ к серверу

Если узел синхронизируется с кластером, выполняя передачу состояния, которая позволяет получить доступ к серверу, например, инкрементную передачу состояния или передачу моментального снимка состояния, использующую метод SST mysqldump, вы можете проверить состояние передачи состояния, подключившись к серверу через mysql клиент, а затем проверив переменные состояния wsrep_local_state_uuid и wsrep_cluster_state_uuid. Когда они будут равны друг другу, узел будет синхронизирован с кластером.

select if((SELECT VARIABLE_VALUE AS "uuid"
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME = "wsrep_cluster_state_uuid")=(SELECT VARIABLE_VALUE AS "uuid"
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME = "wsrep_local_state_uuid"), "Synced", "Not Synced") as "Cluster Status"; 

+----------------+
| Cluster Status |
+----------------+
| Synced         |
+----------------+

Когда локальный и кластерный UUID синхронизируются, узел снова доступен и функционирует как часть кластера.

Передачи состояния, требующие остановки сервера

Некоторые передачи состояния требуют недоступности сервера, например, все методы передачи моментального снимка состояния, кроме mysqldump, поэтому доступ к клиенту mysql недоступен во время передачи состояния. В этих случаях вам может потребоваться отслеживать ход передачи состояния в журнале ошибок. Вы узнаете, когда передача SST завершена, когда узел-участник изменит свое состояние на SYNCED. Например:

2018-08-30 14:44:15 140694729484032 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 210248566)