Zen

Translation

English
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``.)
358/3180 · 318
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,
master #1 has the UUID of master #2, and vice versa.
у мастера №1 UUID мастера №2, и наоборот.

Loading…

User avatar None

String updated in the repository

testing_project / Documentation: book/admin/replication/repl_problem_solving — Russian

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>`.
a year ago
Browse all string changes

Things to check

Mismatched full stop

Source and translation do not both end with a full stop

Reset

Glossary

English Russian
No related strings found in the glossary.

String information

String age
a year ago
Last updated
a year ago
Source string age
a year ago
Translation file
locale/ru/LC_MESSAGES/book/admin/replication/repl_problem_solving.po, string 16