testing_project/Documentation: concepts/replication/repl_architecture — Russian @ Weblate: tarantool> box.space._schema:select{'cluster'} --- - - ['cluster', '6308acb9-9788-42fa-8101-2e0cb9d3c9a0'] ...

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

Translation

English

Russian

Needs editing

Skip

	English	Russian	Actions
	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.	Операции по изменению данных в спейсах с локальной репликацией (спейсах, :doc:`созданных </reference/reference_lua/box_schema/space_create>` с параметром ``is_local = true``) не регистрируются в журнале и не реплицируются.
	To learn how to enable replication, check the :ref:`Bootstrapping a replica set <replication-setup>` guide.	Чтобы узнать, как включить репликацию, перейдите на страницу :ref:`практическое руководство <replication_setup>`.
	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:	Чтобы создать подходящее начальное состояние, к которому можно применить изменения из WAL-файла, для каждого экземпляра из набора реплик должен быть исходный набор :ref:`файлов контрольной точки <index-box_persistence>` -- .snap-файлы для memtx и .run-файлы для vinyl. Когда реплика включается в существующий набор реплик, она выбирает существующего мастера и автоматически загружает с него начальное состояние. Это называется начальным включением.
	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:	Каждый набор реплик можно определить по глобально-уникальному идентификатору, который называется UUID набора реплик. Идентификатор создается мастером во время создания самой первой контрольной точки и является частью файла контрольной точки. Он хранится в системном спейсе :ref:`box.space._schema <box_space-schema>`. Пример:
	tarantool> box.space._schema:select{'cluster'} --- - - ['cluster', '6308acb9-9788-42fa-8101-2e0cb9d3c9a0'] ...	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:	Кроме того, каждому экземпляру в наборе реплик присваивается свой UUID, когда он включается в набор реплик. Такой глобально-уникальный идентификатор называется UUID экземпляра. UUID экземпляра проверяется, чтобы экземпляры не подключались к различным наборам реплик, например, из-за ошибки конфигурации. Уникальный идентификатор экземпляра также необходим для однократного применения строк от разных мастеров, то есть для многомастерной репликации. Вот почему каждая строка в журнале упреждающей записи, помимо номер записи в журнале, хранит идентификатор экземпляра, где запись была создана. Но использование UUID в качестве такого идентификатора заняло бы слишком много места в журнале упреждающей записи, поэтому экземпляру присваивается целое число при включении в набор реплик. Это число, которое называется ID экземпляра, затем используется для ссылок на экземпляр в журнале упреждающей записи. Все идентификаторы хранятся в системном спейсе :ref:`box.space._cluster <box_space-cluster>`. Например:
	tarantool> box.space._cluster:select{} --- - - [1, '88580b5c-4474-43ab-bd2b-2409a9af80d2'] ...	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).	Здесь ID экземпляра -- ``1`` (уникальный номер в рамках набора реплик), а UUID экземпляра -- ``88580b5c-4474-43ab-bd2b-2409a9af80d2`` (глобально уникальный).
	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.	Использование идентификаторов экземпляра также полезно для отслеживания состояния всего набора реплик. Например, :ref:`box.info.vclock <box_introspection-box_info>` описывает состояние репликации в отношении каждого подключенного узла.
	tarantool> box.info.vclock --- - {1: 827, 2: 584} ...	tarantool> box.info.vclock --- - {1: 827, 2: 584} ...
	Here ``vclock`` contains log sequence numbers (827 and 584) for instances with instance IDs ``1`` and ``2``.	Здесь ``vclock`` содержит номера записей в журнале (827 и 584) для экземпляров с идентификаторами экземпляра 1 и 2.
	If required, you can explicitly specify the instance and the replica set UUID values rather than letting Tarantool generate them. To learn more, see the :ref:`replicaset_uuid <cfg_replication-replicaset_uuid>` configuration parameter description.	Начиная с Tarantool 1.7.7, появилась возможность для администраторов назначать UUID экземпляра и UUID набора реплик вместо сгенерированных системой значений -- см. описание конфигурационного параметра :ref:`replicaset_uuid <cfg_replication-replicaset_uuid>`.
	Replication roles: master and replica	Роли в репликации: мастер и реплика
	The replication role (master or replica) is set by the :ref:`read_only <cfg_basic-read_only>` configuration parameter. The recommended role is "read_only" (replica) for all but one instance in the replica set.	Конфигурационный параметр :ref:`read_only <cfg_basic-read_only>` определяет роль в репликации (мастер или реплика). Рекомендованная роль для всех экземпляров в наборе реплик, кроме одного -- "read-only" (реплика).
	In a master-replica configuration, every change that happens on the master will be visible on the replicas, but not vice versa.	В конфигурации мастер-реплика каждое изменение, сделанное на мастере, будет отображаться на репликах, но не наоборот.
	A simple two-instance replica set with the master on one machine and the replica on a different machine provides two benefits:	Простой набор реплик с двумя экземплярами, один из которых является мастером и расположен на одной машине, а другой -- реплика -- расположен на другой машине, дает два преимущества:
	failover, because if the master goes down, then the replica can take over, and	восстановление после отказа, поскольку в случае отказа мастера реплика может взять работу на себя, и
	load balancing, because clients can connect to either the master or the replica for read requests.	балансировка нагрузки, потому что клиенты во время запросов чтения могут подключаться к мастеру или к реплике.
	In a master-master configuration (also called "multi-master"), every change that happens on either instance will be visible on the other one.	В конфигурации мастер-мастер (которая также называется "многомастерной") каждое изменение на любом экземпляре будет также отображаться на другом.
	The failover benefit in this case is still present, and the load-balancing benefit is enhanced, because any instance can handle both read and write requests. Meanwhile, for multi-master configurations, it is necessary to understand the replication guarantees provided by the asynchronous protocol that Tarantool implements.	Восстановление после отказа в таком случае также будет преимуществом, а балансировка нагрузки улучшится, поскольку любой экземпляр может обрабатывать запросы и на чтение, и на запись. В то же время, при многомастерной конфигурации необходимо понимать гарантии репликации, которые обеспечивает асинхронный протокол, внедренный в Tarantool.