The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.
Zen

Source string Source string

283/10000 · 283
English Actions
Replication architecture
Replication mechanism
Overview
A pack of instances that operate on copies of the same databases makes up a **replica set**. Each instance in a replica set has a role: **master** or **replica**.
A replica gets all updates from the master by continuously fetching and applying its :ref:`write-ahead log (WAL) <internals-wal>`. Each record in the WAL represents a single Tarantool data-change request such as :ref:`INSERT <box_space-insert>`, :ref:`UPDATE <box_space-update>`, or :ref:`DELETE <box_space-delete>`, and is assigned a monotonically growing log sequence number (**LSN**). In essence, Tarantool replication is **row-based**: each data-change request is fully deterministic and operates on a single :ref:`tuple <index-box_tuple>`. However, unlike a classical row-based log, which contains entire copies of the changed rows, Tarantool's WAL contains copies of the requests. For example, for UPDATE requests, Tarantool only stores the primary key of the row and the update operations to save space.
`WAL extensions <https://www.tarantool.io/en/enterprise_doc/wal_extensions/>`_ available in Tarantool Enterprise enable you to add auxiliary information to each write-ahead log record. This information might be helpful for implementing a CDC (Change Data Capture) utility that transforms a data replication stream.
The following are specifics of adding different types of information to the WAL:
Invocations of **stored programs** are not written to the WAL. Instead, records of the actual **data-change requests, performed by the Lua code**, are written to the WAL. This ensures that the possible non-determinism of Lua does not cause replication to go out of sync.
Data definition operations on **temporary spaces** (:doc:`created </reference/reference_lua/box_schema/space_create>` with ``temporary = true``), such as creating/dropping, adding indexes, and truncating, are written to the WAL, since information about temporary spaces is stored in non-temporary system spaces, such as :ref:`box.space._space <box_space-space>`.
Data change operations on temporary spaces are not written to the WAL and are not replicated.
Data change operations on **replication-local** spaces (:doc:`created </reference/reference_lua/box_schema/space_create>` with ``is_local = true``) are written to the WAL but are not replicated.
To learn how to enable replication, check the :ref:`Bootstrapping a replica set <replication-setup>` guide.
Replication stages
To create a valid initial state, to which WAL changes can be applied, every instance of a replica set requires a start set of :ref:`checkpoint files <index-box_persistence>`, such as ``.snap`` files for memtx and ``.run`` files for vinyl. A replica goes through the following stages:
**Bootstrap** (optional)
When an entire replica set is bootstrapped for the first time, there is no master that could provide the initial checkpoint. In such a case, replicas connect to each other and elect a master. The master creates the starting set of checkpoint files and distributes them to all the other replicas. This is called an **automatic bootstrap** of a replica set.
**Join**
At this stage, a replica downloads the initial state from the master. The master register this replica in the :ref:`box.space._cluster <box_space-cluster>` space. If join fails with a non-critical :ref:`error <error_codes>`, for example, ``ER_READONLY``, ``ER_ACCESS_DENIED``, or a network-related issue, an instance tries to find a new master to join.
On subsequent connections, a replica downloads all changes happened after the latest local LSN (there can be many LSNs – each master has its own LSN).
**Follow**
At this stage, a replica fetches and applies updates from the master's write-ahead log.
You can use the :ref:`box.info.replication[n].upstream.status <box_info_replication>` property to monitor the status of a replica.
Replica set and instance UUIDs
Each replica set is identified by a globally unique identifier, called the **replica set UUID**. The identifier is created by the master, which creates the very first checkpoint and is part of the checkpoint file. It is stored in the :ref:`box.space._schema <box_space-schema>` system space, for example:
tarantool> box.space._schema:select{'cluster'}
---
- - ['cluster', '6308acb9-9788-42fa-8101-2e0cb9d3c9a0']
...
Additionally, each instance in a replica set is assigned its own UUID, when it joins the replica set. It is called an **instance UUID** and is a globally unique identifier. The instance UUID is checked to ensure that instances do not join a different replica set, e.g. because of a configuration error. A unique instance identifier is also necessary to apply rows originating from different masters only once, that is, to implement multi-master replication. This is why each row in the write-ahead log, in addition to its log sequence number, stores the instance identifier of the instance on which it was created. But using a UUID as such an identifier would take too much space in the write-ahead log, thus a shorter integer number is assigned to the instance when it joins a replica set. This number is then used to refer to the instance in the write-ahead log. It is called **instance ID**. All identifiers are stored in the system space :ref:`box.space._cluster <box_space-cluster>`, for example:
tarantool> box.space._cluster:select{}
---
- - [1, '88580b5c-4474-43ab-bd2b-2409a9af80d2']
...
Here the instance ID is ``1`` (unique within the replica set), and the instance UUID is ``88580b5c-4474-43ab-bd2b-2409a9af80d2`` (globally unique).
Using instance IDs is also handy for tracking the state of the entire replica set. For example, :ref:`box.info.vclock <box_introspection-box_info>` describes the state of replication in regard to each connected peer.

Loading…

User avatar None

New source string

testing_project / Documentation: concepts/replication/repl_architecture — English

To create a valid initial state, to which WAL changes can be applied, every instance of a replica set requires a start set of :ref:`checkpoint files <index-box_persistence>`, such as ``.snap`` files for memtx and ``.run`` files for vinyl. A replica goes through the following stages:
2 years ago
Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Mismatched colon: Russian, Russian

Reset

Glossary

English English
No related strings found in the glossary.

String information

Flags
read-only
String age
2 years ago
Last updated
2 years ago
Source string age
2 years ago
Translation file
string 14