Обновление Tarantool DB¶
Для обновления версии Tarantool DB рекомендуется использовать инсталлятор Ansible Tarantool Enterprise (ATE). Подробная информация об инсталляторе ATE приведена в разделе Установка через Ansible Tarantool Enterprise.
Note
Подробная документация по инсталлятору ATE доступна зарегистрированным пользователям личного кабинета tarantool.io. Узнать больше: Об инсталляторе.
Содержание:
Обновление приложения через 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¶
Note
Если эксплуатация кластера началась сразу с версии 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¶
Note
Если эксплуатация кластера началась сразу с версии 1.2.2, дополнительных действий перед началом работы не требуется.
В версии 1.2.2 в модуле migrations добавлен запрет на изменение применённых миграций.
Хорошая практика работы с модулем предполагает следующее: если миграции уже применены, все дальнейшие изменения схемы данных должны происходить в новых миграциях.
Если вам необходимо использовать возможность менять применённые миграции и вы понимаете возможные риски, запрет на изменение миграций можно отключить.
Для этого в конфигурации кластера в секции migrations.yml задайте для опции is_applied_migrations_writable значение true:
options:
    is_applied_migrations_writable: true