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

Обновление до версии Tarantool DataBase 2.x

В этом руководстве описано, как обновить Tarantool DB версии 1.2.1 и выше до Tarantool DB 2.x. Релизы Tarantool DB 2.x основаны на Tarantool 3.x и несовместимы с Cartridge. Узнать больше о возможностях Tarantool DB 2.х: Tarantool DB 2.0.

Обратите внимание, что установка Tarantool DB 1.2.1 — обязательный шаг перед обновлением на Tarantool DB 2.x. Для использования пользовательского интерфейса необходимо раздеплоить TCM и etcd.

Содержание:

Базовый сценарий миграции с даунтаймом

  1. Выполните резервное копирование кластера. Соответствующая инструкция приведена в документации по инсталлятору ATE в разделе Автоматическое резервирование.

  2. Сгенерируйте конфигурацию кластера Tarantool 3.x c помощью утилиты tools/client/get_tdb2_config.lua:

    ./tarantool tools/client/get_tdb2_config.lua > config.yml

    Здесь:

    • config.yml — файл, в который записывается созданная конфигурация Tarantool 3.x.

    Подробное описание утилиты приведено в разделе Создание конфигурации для кластера Tarantool DB 2.x.

    Теперь проверьте корректность конфигурации и заполните нужные секции. Подробнее про это можно прочитать в разделе Описание конфигурации.

  3. Для работы через ATE требуется файл инвентаря, который содержит описание топологии вашего решения и настроек приложения или продукта. Подготовьте файл инвентаря для Tarantool DB 2.0, используя инструкцию в документации по инсталлятору. Поскольку у вас уже есть готовый файл с конфигурацией кластера, не указывайте в инвентаре поля tarantool_config_global и tarantool_config_replicaset.

    Кроме того, если используется supervised failover, добавьте экземпляры-координаторы:

    tarantooldb_test_env_3:  hosts:    storage-1-2:    storage-2-2:    coordinator-3:      tarantool_coordinator: true

    Смотрите также: Пример инвентаря для Tarantool DB 2.x.

  4. Установите etcd. Для корректной работы необходимо установить минимум 3 экземпляра etcd версии не ниже 3.4. Из-за ограничений инсталлятора ATE использовать Tarantool DB 2.x без etcd нельзя.

  5. Загрузите конфигурацию Tarantool 3.x в etcd. При загрузке конфигурации в etcd используйте ключ /tarantool/{{cartridge_app_name}}/config/all.

    Здесь:

    • {{cartridge_app_name}} — переменная из инвентаря для Tarantool DB версий 1.x и 2.x, обозначающая имя приложения.

    Для загрузки конфигурации можно использовать etcdctl:

    ETCDCTL_API=3 etcdctl --endpoints=http://10.0.1.12:2379 put /tarantool/{{cartridge_app_name}}/config/all -- < config.yml

  6. Разверните Tarantool Cluster Manager, чтобы получить доступ к веб-интерфейсу и обновляться в удобном режиме. Инструкция по запуску TCM приведена в документации инсталлятора ATE.

  7. Настройте веб-интерфейс TCM. Для этого:

    1. Войдите в TCM, используя адрес и пароль из инвентаря TCM — см. опции tcm_host, tcm_port, tcm_bootstrap_password.
    2. Перейдите на вкладку Clusters и нажмите кнопку Add.
    3. Укажите название кластера и добавьте описание для него.
    4. Переключитесь на второй экран настройки, используя кнопку Next.
    5. На втором экране укажите следующие значения:
      • в поле Provider — etcd;
      • в поле Prefix — /tarantool/{{cartridge_app_name}}, где {{cartridge_app_name}} — это переменная из инвентаря;
      • в поле Endpoints укажите эндпоинты etcd в формате http://10.0.1.12:2379.
    6. Переключитесь на третий экран настройки, используя кнопку Next.
    7. На третьем экране укажите следующие значения:
    • в поле Username — admin;
    • в поле Password — пароль для пользователя admin из конфигурации.
    1. В левом верхнем углу нажмите на кнопку Cluster и переключитесь на нужный кластер.
    2. Перейдите во вкладку Configuration. Проверьте, что конфигурация загрузилась из etcd.

  8. Остановите кластер Tarantool DB 1.x. Для этого вы можете использовать сценарий stop.yml.

  9. Разверните Tarantool DB 2.x, используя соответствующий сценарий ATE.

    Пример запуска

    docker run --network host -it --rm \-v ./key:/root/id_private_key:Z \-v ./inventory.yml:/ansible/inventories/hosts_tarantooldb.yml:Z \-v ./tarantooldb-2x-latest.linux.x86_64.tar.gz:/ansible/inventories/tarantooldb-2x-latest.linux.x86_64.tar.gz:Z \-e ENV_SUPER_USER=astra \ansible-tarantool-enterprise:1.4.1 \        ansible-playbook -i /ansible/inventories/hosts_tarantooldb.yml \        --extra-vars '{            "cartridge_package_path":"/ansible/inventories/tarantooldb-2x-latest.linux.x86_64.tar.gz",            "ansible_ssh_private_key_file":"~/id_private_key",            "super_user":"'${ENV_SUPER_USER}'",            "tarantool_shared_become_user":"tarantool",            }' \            /ansible/playbooks/install_3_0.yml --limit tarantooldb_test_env_1,tarantooldb_test_env_2,tarantooldb_test_env_3

  10. Убедитесь, что в TCM все работает корректно. Для этого после запуска откройте в TCM вкладку Stateboard и проверьте, что кластер поднялся. Выберите экземпляр в любом из наборов реплик и в открывшемся окне перейдите во вкладку Terminal. Проверьте, что работают модули crud и dictionary.

  11. Кластер уже готов к работе, но необходимо обновить схему данных. Чтобы обновить схему данных, в TCM на каждом master-узле вызовите box.schema.upgrade.

Описание конфигурации

Утилита get_tdb2_config.lua создаст конфигурацию для текущей топологии кластера, но задать пути до файлов .xlog и .snap вам необходимо вручную.

В разделах ниже рассмотрена по частям конфигурация для кластера с 2 наборами реплик по 2 хранилища и 4 роутерами. Полный список опций конфигурации Tarantool 3.x приведен в документации Tarantool.

Директории с данными

Обратите внимание на секции конфигурации wal и dir. Для успешного запуска необходимо указать корректные пути до директорий с файлами wal и snap для каждого экземпляра.

Здесь:

  • {{ instance_name }} — имя экземпляра в Tarantool 3.x. В Cartridge это alias экземпляра.
wal:  dir: /app/tarantool/tarantooldb/workdir/tarantooldb.{{ instance_name }}/snapshot:  dir: /app/snap/tarantooldb/tarantooldb.{{ instance_name }}/

Tarantool DB не поддерживает спейсы на движке vinyl. Тем не менее, если такие спейсы есть, укажите для них также правильный путь:

vinyl:  dir: /app/tarantool/tarantooldb/workdir/tarantooldb.{{ instance_name }}/

Пользователь admin

В Cartridge-приложении используется один пользователь admin для репликации, шардирования и вызова хранимых процедур. Этот же пользователь admin указывается и в конфигурации Tarantool 3.x.

Также пользователю даются права на исполнение функции failover.execute. Это необходимо при использовании supervised failover.

В качестве пароля укажите cluster cookie.

credentials:  users:    admin:      password: tarantooldb-test      roles:      - super      - sharding      - replication      privileges:      - permissions: ['execute']        functions: ['failover.execute']

Логирование

Теперь настройте логирование в нужный файл:

log:  file: /app/logs/tarantooldb/{{ instance_name }}.log  to: file  level: info

Восстановление после сбоев

В Tarantool 3.x есть три режима восстановления после сбоев (failover):

  • manual — ручное управление лидером в наборе реплик;
  • election — восстановление после сбоев с использованием алгоритма RAFT;
  • supervised — управление восстановлением после сбоев через внешний координатор.

В зависимости от типа фейловера в Cartridge скрипт выставит соответствующее значение для Tarantool 3.x:

Фейловер Cartridge

Фейловер Tarantool 3.x

Disabled

Manual

Eventual

Manual

Raft

Election

Stateful

Supervised

Если вы используете синхронную репликацию, вы сможете выставить только режим election. В противном случае вам необходимо:

  • отказаться от использования синхронной репликации;
  • сделать спейсы асинхронными;
  • выполнить на owner-ах очереди транзакций метод box.ctl.demote.

Чтобы узнать, какая реплика в наборе реплик является owner-ом, вызовите box.info.synchro.

Топология

Скрипт разделит наборы реплик на 3 группы:

  • routers — сюда попадут наборы реплик с ролью vshard-router;
  • storages — сюда попадут наборы реплик с ролью vshard-storage;
  • others — сюда попаду остальные наборы реплик.

При необходимости вы можете перенастроить группы под ваше приложение.

Рассмотрим конфигурацию для набора реплик из группы storages. Скрипт присвоит каждому экземпляру и набору реплик свой UUID. Без них поднять кластер на данных Tarantool DB 1.x не получится. В секциях roles и roles_cfg указаны роли и конфигурации для них в секциях для набора реплик и экземпляра. Скрипт возьмет их из Tarantool DB 1.x и подставит в Tarantool DB 2.x.

Также обратите внимание на параметр memtx.memory для памяти, выделенной на экземпляр. Роль roles.metrics-export отвечает за метрики, получаемые с экземпляра Tarantool 3.x. Для работы этой роли поднимается http-сервер на порту, указнном в опции roles.metrics-export.http.

Если в кластере Tarantool DB 1.x есть особые переменные (например, max_tuple_size, slab_alloc_factor или VINYL_MEMORY), укажите их в данной секции конфигурации. Если этого не сделать, для них будут взяты значения по умолчанию.

leader для набора реплик указывается только при режиме manual в failover.

Пример

storages:    replicasets:      shard-2:        database:          replicaset_uuid: 32d96df2-c2ba-4027-b63d-a42803bb1d50        roles_cfg: {}        roles:        - roles.metrics-export        - roles.expirationd        - roles.dictionary-storage        - roles.crud-storage        leader: storage-2-1 # используется только с failover manual        instances:          storage-2-1:            memtx:              memory: 536870912            database:              instance_uuid: 9feab7ac-e7cd-4b3b-8994-d0adaab4aab7            iproto:              listen:              - uri: 10.0.1.31:3303              advertise:                client: 10.0.1.31:3303            roles_cfg:              roles.metrics-export:                http:                - listen: 8093                  endpoints:                  - path: /metrics                    format: prometheus                  - path: /metrics_json                    format: json          storage-2-2:            memtx:              memory: 536870912            database:              instance_uuid: 6cdf636d-1b87-41d2-8ec6-b544fcdf914b            iproto:              listen:              - uri: 10.0.1.6:3304              advertise:                client: 10.0.1.6:3304            roles_cfg:              roles.metrics-export:                http:                - listen: 8094                  endpoints:                  - path: /metrics                    format: prometheus                  - path: /metrics_json                    format: json

Шардирование

Если количество бакетов в вашем кластере отличается от 30000, обратите внимание на секцию sharding:

sharding:  bucket_count: 30000

Подключения для репликации и шардирования

В секции iproto задайте пользователей для репликации и шардирования. В этом руководстве только один пользователь — admin, его и нужно указать в конфигурации:

iproto:  advertise:    peer:      password: tarantooldb-test      login: admin    sharding:      password: tarantooldb-test      login: admin

Дополнительные параметры

Задайте необходимые параметры в секциях process, security и console:

process:  work_dir: /app/tarantool/tarantooldb/bin/tarantooldb.{{ instance_name }} #рабочая директория  pid_file: /app/tarantool/tarantooldb/run/{{ instance_name }}.pid #pid-файлsecurity: # отключение доступа без пароля как гость  disable_guest: trueconsole: # доступ через unix socket  socket: /app/tarantool/tarantooldb/run/{{ instance_name }}.control  enabled: true

Пример инвентаря Tarantool DB 2.0

---all:  children:    ROUTERS:      children:        router-1:        router-2:        router-3:        router-4:        router-5:        router-6:      vars:    STORAGES:      children:        storage-1:        storage-2:      vars:    storage-1:      hosts:        storage-1-1:        storage-1-2:      vars:        replicaset_alias: storage-1    storage-2:      hosts:        storage-2-1:        storage-2-2:      vars:        replicaset_alias: storage-2    router-1:      hosts:        router-1:      vars:        replicaset_alias: router-1    router-2:      hosts:        router-2:      vars:        replicaset_alias: router-2    router-3:      hosts:        router-3:      vars:        replicaset_alias: router-3    router-4:      hosts:        router-4:      vars:        replicaset_alias: router-4    router-5:      hosts:        router-5:      vars:        replicaset_alias: router-5    router-6:      hosts:        router-6:      vars:        replicaset_alias: router-6    tarantooldb_test_env_1:      hosts:        storage-1-1:        router-1:        router-2:        router-3:        coordinator-1:          tarantool_coordinator: true      vars:        ansible_host: '10.0.1.12'        ansible_user: 'astra'    tarantooldb_test_env_2:      hosts:        storage-2-1:        router-4:        router-5:        router-6:        coordinator-2:          tarantool_coordinator: true      vars:        ansible_host: '10.0.1.31'        ansible_user: 'astra'    tarantooldb_test_env_3:      hosts:        storage-1-2:        storage-2-2:        coordinator-3:          tarantool_coordinator: true      vars:        ansible_host: '10.0.1.6'        ansible_user: 'astra'    etcd_hosts:      hosts:        '10.0.1.12':        '10.0.1.31':        '10.0.1.6':      vars:        ansible_user: 'astra'  vars:    ansible_ssh_common_args: -o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no    ansible_ssh_retries: 5    cartridge_app_name: tarantooldb    tarantool_3_0_version_support: true    tarantool_etcd_host: "10.0.1.12"    etcd_host: "10.0.1.12"    cartridge_failover_params:      state_provider: "etcd2"      etcd2_params:        endpoints:          - http://10.0.1.12:2379          - http://10.0.1.31:2379          - http://10.0.1.6:2379

Пример инвентаря TCM

---cluster-manager:  hosts:    tcm:      tcm_host: localhost      tcm_port: 8081      tcm_etcd_host: "10.0.1.12"      tcm_bootstrap_password: secret      tcm_cluster_tt_command: /app/tarantool/tarantooldb/dist/tdb/tt # укажите путь до tt в вашем контуре      ansible_host: '10.0.1.12'      ansible_user: 'astra'  vars:    ansible_ssh_common_args: -o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

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