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

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

Обновить Tarantool DB можно, используя один из способов ниже:

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

Для обновления Tarantool DB рекомендуется использовать второй способ — обновление приложения без простоя.

Чтобы обновить 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) — версия инсталлятора.

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

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

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

Для обновления Tarantool DB без простоя используется стандартный порядок обновления узлов:

1. Обновление узлов-реплик хранилища
2. Обновление мастер-узлов хранилища
3. Обновление роутеров

Чтобы выполнить обновление продукта до версии 1.2.7 или выше:

1. Выполните обновление версии Tarantool DB в обычном порядке через ATE, используя сценарий update_2x. При работе этого сценария обновление схемы БД через box.schema.upgrade() выполняется автоматически. Подробное описание сценария приведено в документации ATE: Tarantool Cartridge: Обновление приложения без простоя.

   При обновлении можно управлять количеством одновременных обновлений экземпляров хранилища и роутеров. Также обязательными являются переменные 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 — интервал между проверками консистентности кластера.

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

2. После завершения обновления задайте для пользователя, от имени которого выполняются CRUD-операции через роутер, права для выполнения CRUD-операций на чтение и запись данных. Минимальный набор прав включает доступ на чтение и запись в необходимые пользовательские спейсы, доступ на чтение системных спейсов _bucket, _ddl_sharding_key и _ddl_sharding_func, а также доступ на выполнение необходимых методов crud.*. Минимальный набор необходимых разрешений приведен в разделе Чтение и запись данных через модуль CRUD.

Инструкция по обновлению TDB до версии 1.2.6 отличается от общей процедуры и требует выполнения дополнительных шагов. При обновлении до версии TDB 1.2.6:

1. Перед началом обновления создайте с помощью миграции на всех экземплярах хранилища спейс _crud_settings_local, используя скрипт миграции ниже:

    
   local config = require('config')local fun = require('fun')local function is_storage()    return fun.index('roles.crud-storage', config:get('roles')) ~= nilendlocal function apply()    if is_storage() then        local settings_space = box.schema.space.create('_crud_settings_local', {            engine = 'memtx',            is_local = true,            if_not_exists = true,            format = {                { name = 'key', type = 'string' },                { name = 'value', type = 'any' },            },        })        settings_space:create_index('primary', { parts = { 'key' }, if_not_exists = true })    end    return trueendreturn {    apply = {        scenario = apply,    }}

2. После завершения миграции выполните обновление версии Tarantool DB в обычном порядке через ATE. Для обновления используйте сценарий ATE update_2x, приведенный в разделе выше или в документации ATE: Tarantool Cartridge: Обновление приложения без простоя. При работе этого сценария обновление схемы БД через box.schema.upgrade() выполняется автоматически.

3. После завершения обновления задайте для пользователя, от имени которого выполняются CRUD-операции через роутер, права для выполнения CRUD-операций на чтение и запись данных. Минимальный набор прав включает доступ на чтение и запись в необходимые пользовательские спейсы, доступ на чтение системных спейсов _bucket, _ddl_sharding_key и _ddl_sharding_func, а также доступ на выполнение необходимых методов crud.*. Минимальный набор необходимых разрешений приведен в разделе Чтение и запись данных через модуль CRUD.

В версии 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 в модуле migrations добавлен запрет на изменение применённых миграций. Хорошая практика работы с модулем предполагает следующее: если миграции уже применены, все дальнейшие изменения схемы данных должны происходить в новых миграциях.

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

 
options:    is_applied_migrations_writable: true