Обновление

For information about backwards compatibility, see the compatibility guarantees description.

Upgrading Tarantool on a standalone instance

This procedure is for upgrading a standalone Tarantool instance in production. Notice that this will always imply a downtime. To upgrade without downtime, you need several Tarantool servers running in a replication cluster (see below).

Остановите Tarantool-сервер.
Создайте копию всех данных (см. подразделы про горячее резервное копирование в разделе Резервное копирование) и пакета, из которого была установлена текущая (старая) версия (на случай отката).
Обновите Tarantool-сервер. Инструкции по установке доступны на странице загрузок Tarantool.
Run box.schema.upgrade() on the new master. This will update the Tarantool system spaces to match the currently installed version of Tarantool. There is no need to run box.schema.upgrade() on every node: changes are propagated to other nodes via the regular replication mechanism.
При необходимости обновите файлы приложения.
Запустите обновленный Tarantool-сервер с помощью tarantoolctl, tt или systemctl.

Upgrading Tarantool in a replica set with no downtime

Below are the general instructions for upgrading Tarantool in a replica set. Upgrading from some versions can involve certain specifics. You can find instructions for individual versions in the list below.

Важно

The only way to upgrade Tarantool from version 1.6, 1.7, or 1.9 to 2.x without downtime is taking an intermediate step by upgrading to 1.10 and then to 2.x.

Before upgrading Tarantool from 1.6 to 2.x, please read about the associated caveats.

Preparations

Check the replica set health by running the following code on every instance:
```
box.info.ro -- "false" at least on one instance
box.info.status -- should be "running"
```
If all instances have box.info.ro = true, this means there are no writable nodes. If you’re running Tarantool v. 2.10.0 or later, you can find out the reason by running box.info.ro_reason. If it has the value orphan, the instance doesn’t see the rest of the replica set. Similarly, if box.info.status has the value orphan, the instance doesn’t see the rest of the replica set. First resolve the replication issues and only then continue.

If you’re running Cartridge, you can also check node health in the UI.
Make sure each replica is connected to the rest of the replica set. To do this, run box.info.replication in the instance’s console and check the output table for values like upstream, downstream, and lag.

For each instance id, there are upstream and downstream values. Both of them should have the value follow, except on the instance where you run this code. This means that the replicas are connected and there are no errors in the data flow.

The value of the lag field can be less or equal than box.cfg.replication_timeout, but it can also be moderately larger. For example, if box.cfg.replication_timeout is 1 second and the write load on the master is high, it’s generally OK to have a lag of about 10 seconds on the master. It is up to the user to decide what lag values are fine.

If the replica set is healthy, proceed to the upgrade.

Upgrade procedure

Pick any read-only instance in the replica set.
Upgrade this replica to the new Tarantool version. See details in Upgrading Tarantool on a standalone instance. This requires stopping the instance for a while, which won’t interrupt the replica set operation. When the upgraded replica is up again, it will synchronize with the other instances in the replica set so that the data are consistent across all the instances.
Make sure the upgraded replica is running and connected to the rest of the replica set just fine. To do this, run box.info.replication in the instance’s console and check the output table for values like upstream, downstream, and lag.

For each instance id, there are upstream and downstream values. Both of them should have the value follow, except on the instance where you run this code. This means that the replicas are connected and there are no errors in the data flow.

The value of the lag field can be less or equal than box.cfg.replication_timeout, but it can also be moderately larger. For example, if box.cfg.replication_timeout is 1 second and the write load on the master is high, it’s generally OK to have a lag of about 10 seconds on the master. It is up to the user to decide what lag values are fine.
Upgrade all the read-only instances by repeating steps 1–3 until only the master keeps running the old Tarantool version.
Make one of the updated replicas the new master:
- If the replica set is using asynchronous replication without RAFT-based leader elections, first run box.cfg{ read_only = true } on the old master and then run box.cfg{ read_only = false } on the replica that will be the new master.
- If the replica set is using synchronous replication or RAFT-based leader elections, run box.ctl.promote() on the new master and then run box.cfg{ election_mode = 'voter' } on the old master. This will automatically change the read_only statuses on the instances.
- For a Cartridge replica set, it is possible to select the new master in the web UI.
There is no need to restart the new master.

Check that the new master continues following and being followed by all other replicas, similarly to step 3.
Upgrade the former master, which is now a read-only instance.
Run box.schema.upgrade() on the new master. This will update the Tarantool system spaces to match the currently installed version of Tarantool. There is no need to run box.schema.upgrade() on every node: changes are propagated to other nodes via the regular replication mechanism.
Run box.snapshot() on every node in the replica set to make sure that the replicas immediately see the upgraded database state in case of restart.

Версия: