diff --git a/doc/book/admin/_includes/1.6-to-2.x-condition.rst b/doc/book/admin/_includes/1.6-to-2.x-condition.rst new file mode 100644 index 0000000000..cf13cc2ec4 --- /dev/null +++ b/doc/book/admin/_includes/1.6-to-2.x-condition.rst @@ -0,0 +1,12 @@ +Versions later that 1.6 have incompatible :ref:`.snap ` and +:ref:`.xlog ` file formats: 1.6 files are +supported during upgrade, but you won’t be able to return to 1.6 after running +under 1.10 or 2.x for a while. A few configuration parameters are also renamed. + +To perform a **live** upgrade from Tarantool 1.6 to a more recent version, +like :doc:`2.8.4 `, :doc:`2.10.1 ` and such, +it is necessary to take an intermediate step by upgrading 1.6 -> **1.10** -> 2.x. +This is the only way to perform the upgrade **without downtime**. + +However, a direct upgrade of a replica set from 1.6 to 2.x is also possible, but only +**with downtime**. diff --git a/doc/book/admin/_includes/script_find_indices.rst b/doc/book/admin/_includes/script_find_indices.rst new file mode 100644 index 0000000000..2c7b1dfde2 --- /dev/null +++ b/doc/book/admin/_includes/script_find_indices.rst @@ -0,0 +1,54 @@ +local fiber = require('fiber') +local decimal = require('decimal') + +local function isnan(val) + return type(val) == 'number' and val ~= val +end + +local function isinf(val) + return val == math.huge or val == -math.huge +end + +local function vinyl(id) + return box.space[id].engine == 'vinyl' +end + +require_rebuild = {} +local iters = 0 +for _, v in box.space._index:pairs({512, 0}, {iterator='GE'}) do + local id = v[1] + iters = iters + 1 + if iters % 1000 == 0 then + fiber.yield() + end + if vinyl(id) then + local format = v[6] + local check_fields = {} + for _, fmt in pairs(v[6]) do + if fmt[2] == 'number' or fmt[2] == 'scalar' then + table.insert(check_fields, fmt[1] + 1) + end + end + local have_decimal = {} + local have_nan = {} + if #check_fields > 0 then + for k, tuple in box.space[id]:pairs() do + for _, i in pairs(check_fields) do + iters = iters + 1 + if iters % 1000 == 0 then + fiber.yield() + end + have_decimal[i] = have_decimal[i] or + decimal.is_decimal(tuple[i]) + have_nan[i] = have_nan[i] or isnan(tuple[i]) or + isinf(tuple[i]) + if have_decimal[i] and have_nan[i] then + table.insert(require_rebuild, v) + goto out + end + end + end + end + end + ::out:: +end diff --git a/doc/book/admin/_includes/script_rebuild_indices.rst b/doc/book/admin/_includes/script_rebuild_indices.rst new file mode 100644 index 0000000000..caf5695493 --- /dev/null +++ b/doc/book/admin/_includes/script_rebuild_indices.rst @@ -0,0 +1,25 @@ +local log = require('log') + +local function rebuild_index(idx) + local index_name = idx[3] + local space_name = box.space[idx[1]].name + log.info("Rebuilding index %s on space %s", index_name, space_name) + if (idx[2] == 0) then + log.error("Cannot rebuild primary index %s on space %s. Please, ".. + "recreate the space manually", index_name, space_name) + return + end + log.info("Deleting index %s on space %s", index_name, space_name) + local v = box.space._index:delete{idx[1], idx[2]} + if v == nil then + log.error("Couldn't find index %s on space %s", index_name, space_name) + return + end + log.info("Done") + log.info("Creating index %s on space %s", index_name, space_name) + box.space._index:insert(v) +end + +for _, idx in pairs(require_rebuild) do + rebuild_index(idx) +end diff --git a/doc/book/admin/_includes/upgrade_procedure.rst b/doc/book/admin/_includes/upgrade_procedure.rst new file mode 100644 index 0000000000..64ed4ec4bd --- /dev/null +++ b/doc/book/admin/_includes/upgrade_procedure.rst @@ -0,0 +1,46 @@ +1. Pick any read-only instance in the replica set. + +2. Upgrade this replica to the new Tarantool version. See details in + :ref:`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. + +3. 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. + +4. :ref:`Upgrade ` all the read-only instances by repeating steps 1--3 + until only the master keeps running the old Tarantool version. + +5. Make one of the updated replicas the new master: + + - If the replica set is using asynchronous replication without + :ref:`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 :ref:`synchronous replication ` or + :ref:`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. + +6. :ref:`Upgrade ` the former master, which is now a read-only instance. diff --git a/doc/book/admin/upgrades.rst b/doc/book/admin/upgrades.rst index 32c58ffa32..0c4c1a4e5c 100644 --- a/doc/book/admin/upgrades.rst +++ b/doc/book/admin/upgrades.rst @@ -1,152 +1,113 @@ -.. _admin-upgrades: +.. _admin-upgrades: -================================================================================ Upgrades -================================================================================ +======== For information about backwards compatibility, see the :ref:`compatibility guarantees ` description. -.. _admin-upgrades_db: +.. _admin-upgrades_instance: --------------------------------------------------------------------------------- -Upgrading a Tarantool database --------------------------------------------------------------------------------- +Upgrading Tarantool on a standalone instance +-------------------------------------------- -If you created a database with an older Tarantool version and have now installed -a newer version, make the request ``box.schema.upgrade()``. This updates -Tarantool system spaces to match the currently installed version of Tarantool. - -For example, here is what happens when you run ``box.schema.upgrade()`` with a -database created with Tarantool version 1.6.4 to version 1.7.2 (only a small -part of the output is shown): - -.. code-block:: tarantoolsession - - tarantool> box.schema.upgrade() - alter index primary on _space set options to {"unique":true}, parts to [[0,"unsigned"]] - alter space _schema set options to {} - create view _vindex... - grant read access to 'public' role for _vindex view - set schema version to 1.7.0 - --- - ... - -.. _admin-upgrades_instance: - --------------------------------------------------------------------------------- -Upgrading a Tarantool instance --------------------------------------------------------------------------------- - -Tarantool is backward compatible between two adjacent versions. For example, you -should have no or little trouble when upgrading from Tarantool 1.6 to 1.7, or -from Tarantool 1.7 to 2.x. Meanwhile Tarantool 2.x may have incompatible changes -when migrating from Tarantool 1.6. to 2.x directly. - -.. _admin-upgrades_instance_17_to_20: - -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -How to upgrade from Tarantool 1.7 to 2.x -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -1. Stop the Tarantool server. - -2. Make a copy of all data (see an appropriate hot backup procedure in - :ref:`Backups `) and the package from which the current (old) - version was installed (for rollback purposes). - -3. Update the Tarantool server. See installation instructions at Tarantool - `download page `_. +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 :ref:`below `). -4. Launch the updated Tarantool server using ``tarantoolctl`` or ``systemctl``. +#. Stop the Tarantool server. -.. _admin-upgrades_instance_16_to_20: +#. Make a copy of all data (see an appropriate hot backup procedure in + :ref:`Backups `) and the package from which the current (old) + version was installed (for rollback purposes). -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -How to upgrade from Tarantool 1.6 to 2.x -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +#. Update the Tarantool server. See installation instructions at Tarantool + `download page `_. -The procedure is fully analogous to -:ref:`upgrading from 1.7 to 2.x `. +#. Run :ref:`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. -.. _admin-upgrades_instance_16_to_17: +#. Update your application files, if needed. -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -How to upgrade from Tarantool 1.6 to 1.7 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +#. Launch the updated Tarantool server using ``tarantoolctl``, ``tt``, or ``systemctl``. -This procedure is for upgrading a standalone Tarantool instance in production -from 1.6.x to 1.7.x. Notice that this will **always imply a downtime**. -To upgrade **without downtime**, you need several Tarantool servers running in a -replication cluster (see :ref:`below `). +.. _admin-upgrades_replication_cluster: -Tarantool 1.7 has an incompatible :ref:`.snap ` and -:ref:`.xlog ` file format: 1.6 files are -supported during upgrade, but you won’t be able to return to 1.6 after running -under 1.7 for a while. It also renames a few configuration parameters, but old -parameters are supported. The full list of breaking changes is available in -`release notes for Tarantool 1.7 `_. +Upgrading Tarantool in a replica set with no downtime +----------------------------------------------------- -1. Check with application developers whether application files need to be - updated due to incompatible changes (see - `1.7 release notes `_). - If yes, back up the old application files. +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 :ref:`in the list below `. -2. Stop the Tarantool server. +.. important:: -3. Make a copy of all data (see an appropriate hot backup procedure in - :ref:`Backups `) and the package from which the current (old) - version was installed (for rollback purposes). + 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. -4. Update the Tarantool server. See installation instructions at Tarantool - `download page `_. + Before upgrading Tarantool from 1.6 to 2.x, please read about the associated + :ref:`caveats `. -5. Update the Tarantool database. Put the request ``box.schema.upgrade()`` - inside a :doc:`box.once() ` function in your Tarantool - :ref:`initialization file `. - On startup, this will create new system spaces, update data type names (e.g. - num -> unsigned, str -> string) and options in Tarantool system spaces. +Preparations +~~~~~~~~~~~~ -6. Update application files, if needed. +#. Check the replica set health by running the following code on every instance: -7. Launch the updated Tarantool server using ``tarantoolctl`` or ``systemctl``. + .. code-block:: tarantoolsession -.. _admin-upgrades_replication_cluster: + 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 :doc:`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. --------------------------------------------------------------------------------- -Upgrading Tarantool in a replication cluster --------------------------------------------------------------------------------- + If you're running Cartridge, you can also check node health in the UI. -Tarantool 1.7 can work as a :ref:`replica ` -for Tarantool 1.6 and vice versa. Replicas -perform capability negotiation on handshake, and new 1.7 replication features -are not used with 1.6 replicas. This allows upgrading clustered configurations. +#. 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``. -This procedure allows for a rolling upgrade **without downtime** and works for -any cluster configuration: master-master or master-replica. + 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. -1. Upgrade Tarantool at all replicas (or at any master in a master-master - cluster). See details in - :ref:`Upgrading a Tarantool instance `. + 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. -2. Verify installation on the replicas: +Upgrade procedure +~~~~~~~~~~~~~~~~~ - a. Start Tarantool. +.. include:: ./_includes/upgrade_procedure.rst - b. Attach to the master and start working as before. +7. Run :ref:`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. - The master runs the old Tarantool version, which is always compatible with - the next major version. +8. 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. -3. Upgrade the master. The procedure is similar to upgrading a replica. -4. Verify master installation: +.. _admin-upgrades_version_specifics: - a. Start Tarantool with replica configuration to catch up. +Version specifics +----------------- - b. Switch to master mode. +.. toctree:: + :maxdepth: 1 -5. Upgrade the database on any master node in the cluster. Make the request - ``box.schema.upgrade()``. This updates Tarantool system spaces to match the - currently installed version of Tarantool. Changes are propagated to other - nodes via the regular replication mechanism. + upgrades/1.6-1.10 + upgrades/1.6-2.0-downtime + upgrades/2.10.1 diff --git a/doc/book/admin/upgrades/1.6-1.10.rst b/doc/book/admin/upgrades/1.6-1.10.rst new file mode 100644 index 0000000000..02ebe9d05d --- /dev/null +++ b/doc/book/admin/upgrades/1.6-1.10.rst @@ -0,0 +1,65 @@ +.. _admin-upgrades-1.6-1.10: + +Live upgrade from Tarantool 1.6 to 1.10 +======================================= + +This page includes explanations and solutions to some common issues +when upgrading a replica set from Tarantool 1.6 to 1.10. + +.. include:: ../_includes/1.6-to-2.x-condition.rst + +The procedure of live upgrade from 1.6 to 1.10 is similar to the general upgrade procedure, +which is as follows: + +.. include:: ../_includes/upgrade_procedure.rst + +7. Run :ref:`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. + +.. _admin-upgrades-1.6-1.10-step_8: + +8. 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. + +What's different when upgrading from Tarantool 1.6: + +**Step 2:** Tarantool 1.10+ fails to recover from 1.6 xlogs, unless ``box.cfg{force_recovery = true}`` is set. +There is some small difference between 1.6 and 1.10 xlogs, which makes 1.6 xlogs appear erroneous to 1.10+ instances. +In order to work around this, start the instance in ``force_recovery`` mode. To do so, add the line +``force_recovery = true`` to the file where the instance is initialized -- for example, to ``init.lua``. + +**Step 3:** New Tarantool nodes follow 1.6 nodes just fine, +but some 1.6 nodes might disconnect from new nodes with an ER_LOADING error. +This is not critical, the error goes away when replication on 1.6 is restarted: + +.. code-block:: lua + + old_repl = box.cfg.replication + box.cfg{replication = ""} + box.cfg{replication = old_repl} + +**Step 7:** There was a breaking change between 1.6 and 1.10 -- +in 1.6, the field type ``num`` was an alias to ``number``, and in 1.10, ``num`` is converted to ``unsigned``. +This means that after ``box.schema.upgrade()`` is performed on the master, +the user might have some spaces with ``unsigned`` fields containing non-unsigned values: +``double``, ``int``, and so on. +This will make the snapshot inconsistent, unless an extra action is performed after ``box.schema.upgrade()``. +Run this code in the Tarantool console on the new master: + +.. code-block:: lua + + -- First find all spaces containing unsigned fields with non-unsigned values in them. + -- Say, we have one such space denoted problematic_space and the problem is in field problematic_field_no. + a = box.space.problematic_space:format() + a[problematic_field_no].type = 'number' + box.space.problematic_space:format(a) + +Once this is performed on the master, it's safe to proceed to +:ref:`step 8 `, making a snapshot on every node. + +**Step 8:** The user might be concerned with snapshot size in 1.10 -- +it's drastically smaller than the one created by 1.6 (for example, ~300 Mb vs. 6 Gb in some corner cases). +There is nothing to worry about. +Tarantool 1.6 didn't compress snapshots, while Tarantool 1.10 and above does that. diff --git a/doc/book/admin/upgrades/1.6-2.0-downtime.rst b/doc/book/admin/upgrades/1.6-2.0-downtime.rst new file mode 100644 index 0000000000..fb5663329f --- /dev/null +++ b/doc/book/admin/upgrades/1.6-2.0-downtime.rst @@ -0,0 +1,20 @@ +.. _admin-upgrades-1.6-2.x_downtime: + +Upgrade from 1.6 directly to 2.x with downtime +============================================== + +.. include:: ../_includes/1.6-to-2.x-condition.rst + +Here is how to upgrade from Tarantool 1.6 directly to 2.x: + +#. Stop all instances in the replica set. + +#. :ref:`Upgrade ` Tarantool version to 2.x on every instance. + +#. Upgrade the corresponding instance files and applications, if needed. + +#. Start all the instances with Tarantool 2.x. + +#. Execute ``box.schema.upgrade()`` on the master. + +#. Execute ``box.snapshot()`` on every node in the replica set. diff --git a/doc/book/admin/upgrades/2.10.1.rst b/doc/book/admin/upgrades/2.10.1.rst new file mode 100644 index 0000000000..e8d9a7cdbf --- /dev/null +++ b/doc/book/admin/upgrades/2.10.1.rst @@ -0,0 +1,50 @@ +.. _admin-upgrades-2.10.1_decimal: + +Fix decimal values in vinyl spaces when upgrading to 2.10.1 +=========================================================== + +This is an upgrade guide for fixing one specific problem which could happen with decimal values in vinyl spaces. +It's only relevant when you're upgrading from Tarantool version <= 2.10.0 to anything >= 2.10.1. + +Before :tarantool-issue:`6377` was fixed, ``decimal`` and ``double`` values in a ``scalar`` or ``number`` index +could end up in the wrong order after the update. +If such an index has been built for a space that uses the ``vinyl`` storage engine, +the index is persisted and is not rebuilt even after the upgrade. +If this is the case, the user has to rebuild the affected indexes manually. + +Here are the rules to determine whether your installation was affected. +If all of the statements listed below are true, you have to rebuild indexes for the affected ``vinyl`` spaces manually. + +* You were running Tarantool version 2.10.0 and below. +* You have spaces with the ``vinyl`` storage engine. +* The ``vinyl`` spaces have ``number`` or ``scalar`` indexes. +* The tuples in these spaces may contain both ``decimal`` and ``double`` ``Inf`` or ``NaN`` values. + +If this is the case for you, you can run the following script, which will find all the affected indices: + +.. literalinclude:: ../_includes/script_find_indices.rst + :language: lua + +The indices requiring a rebuild will be stored in the ``require_rebuild`` table. +If the table is empty, you're safe and can continue using Tarantool as before. + +If the ``require_rebuild`` table contains some entries, +you can rebuild the affected indices with the following script. + +.. note:: + + Please run the script below only on the master node + and only after all the nodes are upgraded to the new Tarantool version. + +.. literalinclude:: ../_includes/script_rebuild_indices.rst + :language: lua + +The script might fail on some of the indices with the following error: +"Cannot rebuild primary index index_name on space space_name. Please, recreate the space manually". +If this happens, automatic index rebuild is impossible, +and you have to manually re-create the space to ensure data integrity: + +1. Create a new space with the same format as the existing one. +2. Define the same indices on the freshly created space. +3. Iterate over the old space's primary key and insert all the data into the new space. +4. Drop the old space. diff --git a/doc/reference/reference_lua/box_schema/upgrade.rst b/doc/reference/reference_lua/box_schema/upgrade.rst index 5dfbaf2e57..2e654e48d9 100644 --- a/doc/reference/reference_lua/box_schema/upgrade.rst +++ b/doc/reference/reference_lua/box_schema/upgrade.rst @@ -1,11 +1,33 @@ -.. _box_schema-upgrade: +.. _box_schema-upgrade: -=============================================================================== box.schema.upgrade() -=============================================================================== +==================== -.. module:: box.schema +.. module:: box.schema -.. function:: box.schema.upgrade() +.. function:: box.schema.upgrade() - See :ref:`Upgrading a Tarantool database `. + If you created a database with an older Tarantool version and have now installed + a newer version, make the request ``box.schema.upgrade()``. This updates + Tarantool system spaces to match the currently installed version of Tarantool. + + For example, here is what happens when you run ``box.schema.upgrade()`` with a + database created with Tarantool version 1.6.4 to version 1.7.2 (only a small + part of the output is shown): + + .. code-block:: tarantoolsession + + tarantool> box.schema.upgrade() + alter index primary on _space set options to {"unique":true}, parts to [[0,"unsigned"]] + alter space _schema set options to {} + create view _vindex... + grant read access to 'public' role for _vindex view + set schema version to 1.7.0 + --- + ... + + You can also put the request ``box.schema.upgrade()`` + inside a :doc:`box.once() ` function in your Tarantool + :ref:`initialization file `. + On startup, this will create new system spaces, update data type names (for example, + ``num`` -> ``unsigned``, ``str`` -> ``string``) and options in Tarantool system spaces. diff --git a/locale/ru/LC_MESSAGES/book/admin/upgrades.po b/locale/ru/LC_MESSAGES/book/admin/upgrades.po index c7d18173f6..dbd7f3c699 100644 --- a/locale/ru/LC_MESSAGES/book/admin/upgrades.po +++ b/locale/ru/LC_MESSAGES/book/admin/upgrades.po @@ -44,8 +44,8 @@ msgstr "" "---\n" "..." -msgid "Upgrading a Tarantool instance" -msgstr "Обновление экземпляра Tarantool" +msgid "Upgrading Tarantool on a single instance" +msgstr "Обновление одиночного экземпляра Tarantool" msgid "" "Tarantool is backward compatible between two adjacent versions. For example," @@ -81,9 +81,9 @@ msgstr "" "загрузок Tarantool `_." msgid "" -"Launch the updated Tarantool server using ``tarantoolctl`` or ``systemctl``." +"Launch the updated Tarantool server using ``tarantoolctl``, ``tt``, or ``systemctl``." msgstr "" -"Запустите обновленный Tarantool-сервер с помощью ``tarantoolctl`` или " +"Запустите обновленный Tarantool-сервер с помощью ``tarantoolctl``, ``tt`` или " "``systemctl``." msgid "How to upgrade from Tarantool 1.6 to 2.x" @@ -141,21 +141,21 @@ msgstr "" "резервные копии старых файлов приложения." msgid "" -"Update the Tarantool database. Put the request ``box.schema.upgrade()`` " +"You can also put the request ``box.schema.upgrade()`` " "inside a :doc:`box.once() ` function in " "your Tarantool :ref:`initialization file `. On startup, " "this will create new system spaces, update data type names (e.g. num -> " "unsigned, str -> string) and options in Tarantool system spaces." msgstr "" -"Обновите базу данных Tarantool. Выполните команду ``box.schema.upgrade()``, " +"Выполнить команду ``box.schema.upgrade()`` также можно, " "поместив ее внутрь функции :doc:`box.once() " "` в :ref:`файле инициализации ` Tarantool. В результате на этапе запуска Tarantool создаст " -"новые системные спейсы, обновит названия типов данных (например, num -> " -"unsigned, str -> string) и список доступных типов данных в системных " +"новые системные спейсы, обновит названия типов данных (например, ``num`` -> " +"``unsigned``, ``str`` -> ``string``) и список доступных типов данных в системных " "спейсах." -msgid "Update application files, if needed." +msgid "Update your application files, if needed." msgstr "При необходимости обновите файлы приложения." msgid "Upgrading Tarantool in a replication cluster"