testing_project/Documentation: book/admin/replication/repl_problem_solving — Russian @ Weblate: tarantool> box.space.tester:insert{1, 'data'}

Zen

	English	Russian	Actions
	Resolving replication conflicts	Решение конфликтов репликации
	Solving problems with master-master replication	Устранение конфликтов репликации мастер-мастер
	Tarantool guarantees that every update is applied only once on every replica. However, due to the asynchronous nature of replication, the order of updates is not guaranteed. We now analyze this problem with more details, provide examples of replication going out of sync, and suggest solutions.	Tarantool гарантирует, что все обновления применяются однократно на каждой реплике. Однако, поскольку репликация носит асинхронный характер, порядок обновлений не гарантируется. Сейчас мы проанализируем данную проблему более подробно с примерами рассинхронизации репликации и предложим соответствующие решения.
	Replacing the same primary key	Замена по одному и тому же первичному ключу
	Case 1: You have two instances of Tarantool. For example, you try to make a ``replace`` operation with the same primary key on both instances in the same time. This will cause a conflict over which tuple to save and which one to discard.	Кейс 1: у вас есть два экземпляра Тарантула. Например, вы пытаетесь сделать операцию замены одного и того же первичного ключа на обоих экземплярах одновременно. Случится конфликт из-за того, какой кортеж сохранить, а какой отбросить.
	Tarantool :ref:`trigger functions <triggers>` can help here to implement the rules of conflict resolution on some condition. For example, if you have a timestamp, you can declare saving the tuple with the bigger one.	:ref:`Триггер-функции <triggers>` Тарантула могут помочь в реализации правил разрешения конфликтов при определенных условиях. Например, если у вас есть метка времени, то можно указать, что сохранять нужно кортеж с большей меткой.
	First, you need a :ref:`before_replace() <box_space-before_replace>` trigger on the space which may have conflicts. In this trigger you can compare the old and new replica records and choose which one to use (or skip the update entirely, or merge two records together).	Во-первых, вам нужно повесить триггер :ref:`before_replace() <box_space-before_replace>` на спейс, в котором могут быть конфликты. В этом триггере вы можете сравнить старую и новую записи реплики и выбрать, какую из них использовать (или полностью пропустить обновление, или объединить две записи вместе).
	Then you need to set the trigger at the right time, before the space starts to receive any updates. The way you usually set the ``before_replace`` trigger is right when the space is created, so you need a trigger to set another trigger on the system space ``_space``, to capture the moment when your space is created and set the trigger there. This can be an :ref:`on_replace() <box_space-on_replace>` trigger.	Затем вам нужно установить триггер в нужное время, прежде чем спейс начнет получать обновления. Триггер ``before_replace`` нужно устанавливать в тот момент, когда спейс создается, поэтому еще нужен триггер, чтобы установить другой триггер на системном спейсе ``_space``, чтобы поймать момент, когда ваш спейс создается, и установить триггер там. Для этого подходит триггер :ref:`on_replace() <box_space-on_replace>`.
	The difference between ``before_replace`` and ``on_replace`` is that ``on_replace`` is called after a row is inserted into the space, and ``before_replace`` is called before that.	Разница между ``before_replace`` и ``on_replace`` заключается в том, что ``on_replace`` вызывается после вставки строки в спейс, а ``before_replace`` вызывается перед ней.
	To set a ``_space:on_replace()`` trigger correctly, you also need the right timing. The best timing to use it is when ``_space`` is just created, which is the :ref:`box.ctl.on_schema_init() <box_ctl-on_schema_init>` trigger.	Устанавливать триггер ``_space:on_replace()`` также нужно в определенный момент. Лучшее время для его использования -- это когда только что создан ``_space``, что является триггером на :ref:`box.ctl.on_schema_init() <box_ctl-on_schema_init>`.
	You will also need to utilize ``box.on_commit`` to get access to the space being created. The resulting snippet would be the following:	Вам также нужно использовать ``box.on_commit``, чтобы получить доступ к создаваемому спейсу. В результате код будет выглядеть следующим образом:
	local my_space_name = 'my_space' local my_trigger = function(old, new) ... end -- your function resolving a conflict box.ctl.on_schema_init(function() box.space._space:on_replace(function(old_space, new_space) if not old_space and new_space and new_space.name == my_space_name then box.on_commit(function() box.space[my_space_name]:before_replace(my_trigger) end end end) end)	local my_space_name = 'my_space' local my_trigger = function(old, new) ... end -- ваша функция, устраняющая конфликт box.ctl.on_schema_init(function() box.space._space:on_replace(function(old_space, new_space) if not old_space and new_space and new_space.name == my_space_name then box.on_commit(function() box.space[my_space_name]:before_replace(my_trigger) end end end) end)
	Preventing duplicate insert	Предотвращение дублирующей вставки
	Case 2: In a replica set of two masters, suppose master #1 tries to ``insert`` a tuple with the same unique key:	Кейс 2: Предположим, что в наборе реплик с двумя мастерами мастер №1 пытается вставить кортеж с одинаковым уникальным ключом:
	tarantool> box.space.tester:insert{1, 'data'}	tarantool> box.space.tester:insert{1, 'data'}
	This would cause an error saying ``Duplicate key exists in unique index 'primary' in space 'tester'`` and the replication would be stopped. (This is the behavior when the :ref:`replication_skip_conflict <cfg_replication-replication_skip_conflict>` configuration parameter has its default recommended value, ``false``.)	Это вызовет сообщение об ошибке дубликата ключа (``Duplicate key exists in unique index 'primary' in space 'tester'``), и репликация остановится. Такое поведение системы обеспечивается использованием рекомендуемого значения ``false`` (по умолчанию) для конфигурационного параметра :ref:`replication_skip_conflict <cfg_replication-replication_skip_conflict>`.
	$ # error messages from master #1 2017-06-26 21:17:03.233 [30444] main/104/applier/rep_user@100.96.166.1 I> can't read row 2017-06-26 21:17:03.233 [30444] main/104/applier/rep_user@100.96.166.1 memtx_hash.cc:226 E> ER_TUPLE_FOUND: Duplicate key exists in unique index 'primary' in space 'tester' 2017-06-26 21:17:03.233 [30444] relay/[::ffff:100.96.166.178]/101/main I> the replica has closed its socket, exiting 2017-06-26 21:17:03.233 [30444] relay/[::ffff:100.96.166.178]/101/main C> exiting the relay loop $ # error messages from master #2 2017-06-26 21:17:03.233 [30445] main/104/applier/rep_user@100.96.166.1 I> can't read row 2017-06-26 21:17:03.233 [30445] main/104/applier/rep_user@100.96.166.1 memtx_hash.cc:226 E> ER_TUPLE_FOUND: Duplicate key exists in unique index 'primary' in space 'tester' 2017-06-26 21:17:03.234 [30445] relay/[::ffff:100.96.166.178]/101/main I> the replica has closed its socket, exiting 2017-06-26 21:17:03.234 [30445] relay/[::ffff:100.96.166.178]/101/main C> exiting the relay loop	$ # сообщения об ошибках от мастера №1 2017-06-26 21:17:03.233 [30444] main/104/applier/rep_user@100.96.166.1 I> can't read row 2017-06-26 21:17:03.233 [30444] main/104/applier/rep_user@100.96.166.1 memtx_hash.cc:226 E> ER_TUPLE_FOUND: Duplicate key exists in unique index 'primary' in space 'tester' 2017-06-26 21:17:03.233 [30444] relay/[::ffff:100.96.166.178]/101/main I> the replica has closed its socket, exiting 2017-06-26 21:17:03.233 [30444] relay/[::ffff:100.96.166.178]/101/main C> exiting the relay loop $ # сообщения об ошибках от мастера №2 2017-06-26 21:17:03.233 [30445] main/104/applier/rep_user@100.96.166.1 I> can't read row 2017-06-26 21:17:03.233 [30445] main/104/applier/rep_user@100.96.166.1 memtx_hash.cc:226 E> ER_TUPLE_FOUND: Duplicate key exists in unique index 'primary' in space 'tester' 2017-06-26 21:17:03.234 [30445] relay/[::ffff:100.96.166.178]/101/main I> the replica has closed its socket, exiting 2017-06-26 21:17:03.234 [30445] relay/[::ffff:100.96.166.178]/101/main C> exiting the relay loop
	If we check replication statuses with ``box.info``, we will see that replication at master #1 is stopped (``1.upstream.status = stopped``). Additionally, no data is replicated from that master (section ``1.downstream`` is missing in the report), because the downstream has encountered the same error:	Если мы проверим статус репликации с помощью ``box.info``, то увидим, что репликация на мастере №1 остановлена (``1.upstream.status = stopped``). Кроме того, данные с этого мастера не реплицируются (группа ``1.downstream`` отсутствует в отчете), поскольку встречается та же ошибка:
	# replication statuses (report from master #3) tarantool> box.info --- - version: 1.7.4-52-g980d30092 id: 3 ro: false vclock: {1: 9, 2: 1000000, 3: 3} uptime: 557 lsn: 3 vinyl: [] cluster: uuid: 34d13b1a-f851-45bb-8f57-57489d3b3c8b pid: 30445 status: running signature: 1000012 replication: 1: id: 1 uuid: 7ab6dee7-dc0f-4477-af2b-0e63452573cf lsn: 9 upstream: peer: replicator@192.168.0.101:3301 lag: 0.00050592422485352 status: stopped idle: 445.8626639843 message: Duplicate key exists in unique index 'primary' in space 'tester' 2: id: 2 uuid: 9afbe2d9-db84-4d05-9a7b-e0cbbf861e28 lsn: 1000000 upstream: status: follow idle: 201.99915885925 peer: replicator@192.168.0.102:3301 lag: 0.0015020370483398 downstream: vclock: {1: 8, 2: 1000000, 3: 3} 3: id: 3 uuid: e826a667-eed7-48d5-a290-64299b159571 lsn: 3 uuid: e826a667-eed7-48d5-a290-64299b159571 ...	# статусы репликации (отчет от мастера №3) tarantool> box.info --- - version: 1.7.4-52-g980d30092 id: 3 ro: false vclock: {1: 9, 2: 1000000, 3: 3} uptime: 557 lsn: 3 vinyl: [] cluster: uuid: 34d13b1a-f851-45bb-8f57-57489d3b3c8b pid: 30445 status: running signature: 1000012 replication: 1: id: 1 uuid: 7ab6dee7-dc0f-4477-af2b-0e63452573cf lsn: 9 upstream: peer: replicator@192.168.0.101:3301 lag: 0.00050592422485352 status: stopped idle: 445.8626639843 message: Duplicate key exists in unique index 'primary' in space 'tester' 2: id: 2 uuid: 9afbe2d9-db84-4d05-9a7b-e0cbbf861e28 lsn: 1000000 upstream: status: follow idle: 201.99915885925 peer: replicator@192.168.0.102:3301 lag: 0.0015020370483398 downstream: vclock: {1: 8, 2: 1000000, 3: 3} 3: id: 3 uuid: e826a667-eed7-48d5-a290-64299b159571 lsn: 3 uuid: e826a667-eed7-48d5-a290-64299b159571 ...
	When replication is later manually resumed:	Когда позднее репликация возобновлена вручную:
	# resuming stopped replication (at all masters) tarantool> original_value = box.cfg.replication tarantool> box.cfg{replication={}} tarantool> box.cfg{replication=original_value}	# возобновление остановленной репликации (на всех мастерах) tarantool> original_value = box.cfg.replication tarantool> box.cfg{replication={}} tarantool> box.cfg{replication=original_value}
	... the faulty row in the write-ahead-log files is skipped.	... запись с ошибкой в журнале упреждающей записи пропущена.
	Solution #1: replication runs out of sync	Решение #1: рассинхронизация репликации
	In a master-master cluster of two instances, suppose we make the following operation:	Предположим, что мы выполняем следующую операцию в кластере из двух экземпляров с конфигурацией мастер-мастер:
	tarantool> box.space.tester:upsert({1}, {{'=', 2, box.info.uuid}})	tarantool> box.space.tester:upsert({1}, {{'=', 2, box.info.uuid}})
	When this operation is applied on both instances in the replica set:	Когда эта операция применяется на обоих экземплярах в наборе реплик:
	# at master #1 tarantool> box.space.tester:upsert({1}, {{'=', 2, box.info.uuid}}) # at master #2 tarantool> box.space.tester:upsert({1}, {{'=', 2, box.info.uuid}})	# на мастере #1 tarantool> box.space.tester:upsert({1}, {{'=', 2, box.info.uuid}}) # на мастере #2 tarantool> box.space.tester:upsert({1}, {{'=', 2, box.info.uuid}})
	... we can have the following results, depending on the order of execution:	... можно получить следующие результаты в зависимости от порядка выполнения:
	each master’s row contains the UUID from master #1,	каждая строка мастера содержит UUID из мастера №1,
	each master’s row contains the UUID from master #2,	каждая строка мастера содержит UUID из мастера №2,