TDB Documentation portal logo
Помощь
Обновлена 30 июля 2026 г. в 16:49

Обновление Tarantool DataBase

Для обновления версии Tarantool DB рекомендуется использовать инсталлятор Ansible Tarantool Enterprise (ATE). Подробная информация об инсталляторе ATE приведена в разделе Установка через Ansible Tarantool Enterprise.

Содержание:

Обновление приложения через ATE с помощью Docker

Чтобы обновить Tarantool DB, используйте команду ниже. Команда производит одновременный перезапуск всех экземпляров Tarantool на всех серверах. Рекомендуется использовать на тестовых контурах, если необходимо ускорить развертывание.

docker run --network host -it --rm \    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    -e PACKAGE_NAME=${PACKAGE_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars '{        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",        "super_user":"'${SUPER_USER_NAME}'",        "tarantool_shared_become_user":"tarantool",    }' \    playbooks/update.yml

Здесь:

  • PATH_TO_PRIVATE_KEY (string) — полный путь к приватному ключу;
  • PATH_TO_INVENTORY (string) — полный путь к файлу инвентаря. Пример инвентаря приведен в разделе Подготовка к использованию;
  • PATH_TO_PACKAGE (string) — путь к архиву Tarantool DB;
  • PACKAGE_NAME (string) — название архива Tarantool DB;
  • SUPER_USER_NAME (string) — имя пользователя для подключения по SSH;
  • DEPLOY_TOOL_VERSION_TAG (string) — версия инсталлятора.

Узнать больше: Переменные окружения.

Обновление приложения без простоя через ATE с помощью Docker

Типичная топология кластеров Tarantool подразумевает наличие двух датацентров — активного и резервного. Каждый набор реплик хранилища имеет одну или несколько реплик в обоих датацентрах.

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

При обновлении можно управлять количеством одновременных обновлений экземпляров хранилища и роутеров. Также обязательными являются переменные TARANTOOL_ACTIVE и tarantool_reserve.

docker run --network host -it --rm \    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    -e PACKAGE_NAME=${PACKAGE_NAME} \    -e CLUSTER_IS_HEALTHY_RETRIES=100 \    -e CLUSTER_IS_HEALTHY_DELAY=10 \    -e STORAGES_BATCH_SIZE=2 \    -e ROUTERS_BATCH_SIZE=2 \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars '{        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",        "super_user":"'${SUPER_USER_NAME}'",        "tarantool_shared_become_user":"tarantool",        "wait_members_alive_retries":"'${CLUSTER_IS_HEALTHY_RETRIES}'",        "wait_members_alive_delay":"'${CLUSTER_IS_HEALTHY_DELAY}'",        "wait_cluster_has_no_issues_retries":"'${CLUSTER_IS_HEALTHY_RETRIES}'",        "wait_cluster_has_no_issues_delay":"'${CLUSTER_IS_HEALTHY_DELAY}'",        "storages_batch_size":"'${STORAGES_BATCH_SIZE}'",        "routers_batch_size":"'${ROUTERS_BATCH_SIZE}'",        "tarantool_active":"'${TARANTOOL_ACTIVE}'",        "tarantool_reserve":"'${TARANTOOL_RESERVE}'"    }' \    playbooks/update_2x.yml

Здесь:

  • PATH_TO_PRIVATE_KEY (string) — полный путь к приватному ключу;
  • PATH_TO_INVENTORY (string) — полный путь к файлу инвентаря. Пример инвентаря приведен в разделе Подготовка к использованию;
  • PATH_TO_PACKAGE (string) — путь к архиву Tarantool DB;
  • PACKAGE_NAME (string) — название архива Tarantool DB;
  • SUPER_USER_NAME (string) — имя пользователя для подключения по SSH;
  • DEPLOY_TOOL_VERSION_TAG (string) — версия инсталлятора;
  • TARANTOOL_ACTIVE (string) — группа хостов, которая состоит из всех экземпляров Tarantool в активном датацентре. Активным является датацентр, который принимает пользовательские запросы и включает в себя всех leader наборов репллик;
  • TARANTOOL_RESERVE (string) — хосты, не попавшие в TARANTOOL_ACTIVE. Группа хостов, состоящая из всех экземпляров Tarantool в резервном датацентре.
  • STORAGES_BATCH_SIZE (number) — количество экземпляров с ролью storage, которые обновляются одновременно;
  • ROUTERS_BATCH_SIZE (number) — количество экземпляров с ролью router или runner, которые обновляются одновременно;
  • CLUSTER_IS_HEALTHY_RETRIES (number):
    • wait_members_alive_retries — количество проверок доступности экземпляров;
    • wait_cluster_has_no_issues_retries — количество проверок консистентности кластера;
  • CLUSTER_IS_HEALTHY_DELAY (number):
    • wait_members_alive_delay — интервал между проверками доступности экземпляров;
    • wait_cluster_has_no_issues_delay — интервал между проверками консистентности кластера.

Узнать больше: Переменные окружения.

Дополнительные шаги после установки через ATE

Версия 1.1.0

В версии 1.1.0 существенно обновлен модуль migrations. В частности, в модуле изменён способ хранения названий применённых миграций. Теперь список применённых миграций хранится по отдельности на каждом узле кластера в спейсе _migrations.

Чтобы модуль migrations работал корректно при обновлении с предыдущих версий на версию 1.1.0, выполните одно из действий ниже:

  • Вызовите данный CURL-запрос на любом узле кластера Tarantool DB:

    curl -X POST http://<your_tarantool_ip>:<http_port>/migrations/move_migrations_state

  • Подключитесь к любому узлу кластера Tarantool DB и выполните следующую команду:

    require('migrator').move_migrations_state()

Метод move_migrations_state() копирует имена применённых миграций из конфигурации всего кластера в спейс _migrations на лидерах. Если копирование на все лидеры завершено успешно, метод удаляет список применённых миграций из конфигурации всего кластера.

Версия 1.2.2

В версии 1.2.2 в модуле migrations добавлен запрет на изменение применённых миграций. Хорошая практика работы с модулем предполагает следующее: если миграции уже применены, все дальнейшие изменения схемы данных должны происходить в новых миграциях.

Если вам необходимо использовать возможность менять применённые миграции и вы понимаете возможные риски, запрет на изменение миграций можно отключить. Для этого в конфигурации кластера в секции migrations.yml задайте для опции is_applied_migrations_writable значение true:

options:    is_applied_migrations_writable: true

Была ли статья полезна?