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