Горячее обновление с Tarantool 1.6 до 1.10

На этой странице приведены пояснения и решения типичных проблем, возникающих при обновлении набора реплик с Tarantool 1.6 до 1.10.

В версиях, вышедших после 1.6, форматы файлов .snap и .xlog несовместимы: файлы версии 1.6 поддерживаются при обновлении, но вернуться к версии 1.6 после работы под управлением 1.10 или 2.x не получится. Также переименованы некоторые параметры конфигурации.

Для выполнения обновления без простоя с Tarantool 1.6 до более новой версии, например 2.8.4, 2.10.1 и т.д., необходим промежуточный шаг: обновление 1.6 -> 1.10 -> 2.x.

Прямое обновление набора реплик с 1.6 до 2.x возможно только с простоем.

Процедура горячего обновления с 1.6 до 1.10 аналогична общей процедуре обновления кластера, но с небольшими отличиями на этапе обновления хранилищ. Ниже описана общая процедура обновления хранилища и примечания, относящиеся к версии 1.6, для каждого шага.

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

1. Выберите реплику (экземпляр только для чтения) из набора реплик. Остановите эту реплику и запустите её снова на целевой версии Tarantool. Дождитесь, пока она достигнет статуса running (box.info.status == running).
2. Поочередно перезапустите все остальные экземпляры только для чтения из набора реплик на целевой версии.
3. Назначьте одну из обновленных реплик новым мастером, следуя инструкции из раздела Переключение мастера.
4. Перезапустите последний экземпляр набора реплик (бывший мастер, теперь реплика) на целевой версии.
5. Выполните функцию box.schema.upgrade() на новом мастере. Это обновит системные спейсы Tarantool до текущей установленной версии. Позже механизм репликации передаст изменения на другие узлы.
6. Выполните функцию box.snapshot() на каждом узле набора реплик, чтобы реплики сразу увидели обновленное состояние базы данных при перезапуске.

• Проверка репликации: Новые узлы Tarantool корректно следуют за узлами 1.6, но некоторые узлы 1.6 могут отключаться от новых узлов с ошибкой ER_LOADING. Это не критично - ошибка исчезает после перезапуска репликации на 1.6:

   
  old_repl = box.cfg.replicationbox.cfg{replication = ""}box.cfg{replication = old_repl}

• Точка невозврата: При обновлении с Tarantool 1.6 шаг 3 (переключение мастера) является точкой невозврата. После его выполнения схема больше не совместима с исходной версией.

• Перезапуск на целевой версии (шаги 1, 2 и 4): Tarantool 1.10+ не может восстановиться из xlog-файлов версии 1.6, если не задан параметр box.cfg{force_recovery = true}. Между xlog-файлами версий 1.6 и 1.10 есть небольшое различие, из-за которого xlog-файлы 1.6 воспринимаются экземплярами 1.10+ как ошибочные. Чтобы обойти эту проблему, запустите экземпляр в режиме force_recovery. Для этого добавьте строку force_recovery = true в файл инициализации экземпляра - например, в init.lua.

• Выполнение box.schema.upgrade() (шаг 5): Между версиями 1.6 и 1.10 было внесено несовместимое изменение – в 1.6 тип поля num был псевдонимом для number, а в 1.10 num преобразуется в unsigned. Это означает, что после выполнения box.schema.upgrade() на мастере у пользователя могут остаться спейсы с полями типа unsigned, содержащими значения, не относящиеся к типу unsigned: double, int и так далее. Это приведет к несогласованности снимка состояния, если после box.schema.upgrade() не выполнить дополнительные действия. Выполните следующий код в консоли Tarantool на новом мастере:

   
  -- First find all spaces containing unsigned fields with non-unsigned values in them.-- Say, we have one such space denoted problematic_space and the problem is in field problematic_field_no.a = box.space.problematic_space:format()a[problematic_field_no].type = 'number'box.space.problematic_space:format(a)

• Создание снимков состояния (шаг 6): Размер снимка в 1.10 значительно меньше, чем в версии 1.6 (может составлять ~300 МБ против 6 ГБ в некоторых случаях). Это объясняется тем, что Tarantool 1.6 не сжимал снимки состояния, а Tarantool 1.10 и более новых версий делает это.