В этом разделе приводится подробная информация о функциях, которые можно использовать для обнаружения и разрешения конфликтов с репликацией NDB.

NDB$OLD()

Если значение column_name одинаково как на источнике, так и на реплике, то обновление применяется; в противном случае обновление не применяется на реплике, и в журнал записывается исключение. Это иллюстрируется следующим псевдокодом:

if (source_old_column_value == replica_current_column_value)
  apply_update();
else
  log_exception();

Эта функция может использоваться для разрешения конфликтов по принципу “выигрывает одинаковое значение”. Этот тип разрешения конфликтов гарантирует, что обновления не применяются на реплике из неправильного источника.

NDB$MAX()

Для операции обновления или удаления, если значение столбца “timestamp” для данной строки, поступающей из источника, выше, чем на реплике, оно применяется; в противном случае оно не применяется на реплике. Это иллюстрируется следующим псевдокодом:

if (source_new_column_value > replica_current_column_value)
  apply_update();

Эта функция может использоваться для разрешения конфликтов по принципу “выигрывает наибольшая метка времени”. Этот тип разрешения конфликтов гарантирует, что в случае конфликта сохраняется версия строки, которая была обновлена последней.

Эта функция не влияет на конфликты между операциями записи, за исключением того, что операция записи с тем же первичным ключом, что и предыдущая запись, всегда отклоняется; она принимается и применяется только в том случае, если операция записи с использованием того же первичного ключа еще не существует. Вы можете использовать NDB$MAX_INS() для обработки разрешения конфликтов между записями.

NDB$MAX_DELETE_WIN()

Это вариация на тему NDB$MAX(). Из-за того, что для операции удаления метка времени недоступна, удаление с использованием NDB$MAX() фактически обрабатывается как NDB$OLD, но для некоторых вариантов использования это не оптимально. Для NDB$MAX_DELETE_WIN(), если значение столбца “timestamp” для данной строки, добавляющей или обновляющей существующую строку, поступающей из источника, выше, чем на реплике, оно применяется. Однако операции удаления всегда рассматриваются как имеющие более высокое значение. Это иллюстрируется следующим псевдокодом:

if ( (source_new_column_value > replica_current_column_value)
        ||
      operation.type == "delete")
  apply_update();

Эта функция может использоваться для разрешения конфликтов по принципу “наибольшая метка времени, выигрывает удаление”. Этот тип разрешения конфликтов гарантирует, что в случае конфликта сохраняется версия строки, которая была удалена или (иначе) обновлена последней.

NDB$MAX_INS()

Эта функция обеспечивает поддержку разрешения конфликтующих операций записи. Такие конфликты обрабатываются “NDB$MAX_INS()” следующим образом:

При обработке операции вставки, NDB$MAX_INS() сравнивает метки времени из источника и реплики, как показано в следующем псевдокоде:

if (source_new_column_value > replica_current_column_value)
  apply_insert();
else
  log_exception();

Для операции обновления обновленное значение столбца метки времени из источника сравнивается со значением столбца метки времени реплики, как показано здесь:

if (source_new_column_value > replica_current_column_value)
  apply_update();
else
  log_exception();

Это то же самое, что выполняется NDB$MAX().

Для операций удаления обработка также такая же, как та, которая выполняется NDB$MAX() (и, следовательно, такая же, как NDB$OLD()), и выполняется так:

if (source_new_column_value == replica_current_column_value)
  apply_delete();
else
  log_exception();

NDB$MAX_DEL_WIN_INS()

Эта функция обеспечивает поддержку разрешения конфликтующих операций записи, а также разрешения “выигрывает удаление”, как у NDB$MAX_DELETE_WIN(). Конфликты записи обрабатываются NDB$MAX_DEL_WIN_INS(), как показано здесь:

Обработка операций вставки, выполняемая NDB$MAX_DEL_WIN_INS(), может быть представлена в псевдокоде, как показано здесь:

if (source_new_column_value > replica_current_column_value)
  apply_insert();
else
  log_exception();

Для операций обновления обновленное значение столбца метки времени из источника сравнивается со значением столбца метки времени реплики, так (снова используя псевдокод):

if (source_new_column_value > replica_current_column_value)
  apply_update();
else
  log_exception();

Удаления обрабатываются с использованием стратегии “удаление всегда выигрывает” (то же самое, что и NDB$MAX_DELETE_WIN()); DELETE всегда применяется без учета каких-либо значений меток времени, как показано в этом псевдокоде:

if (operation.type == "delete")
  apply_delete();

Для конфликтов между операциями обновления и удаления эта функция ведет себя идентично NDB$MAX_DELETE_WIN().

NDB$EPOCH()

Функция NDB$EPOCH() отслеживает порядок, в котором реплицированные эпохи применяются в кластере реплик относительно изменений, возникающих на реплике. Этот относительный порядок используется для определения того, являются ли изменения, возникающие на реплике, одновременными с любыми изменениями, которые происходят локально, и поэтому потенциально находятся в конфликте.

Большая часть того, что следует в описании NDB$EPOCH(), также относится к NDB$EPOCH_TRANS(). Любые исключения указаны в тексте.

NDB$EPOCH() является асимметричной, работающей на одном кластере NDB в конфигурации двунаправленной репликации (иногда называемой репликацией “активный-активный”). Здесь мы называем кластер, на котором она работает, первичным, а другой - вторичным. Реплика на первичном кластере отвечает за обнаружение и обработку конфликтов, тогда как реплика на вторичном кластере не участвует ни в каком обнаружении или обработке конфликтов.

Когда реплика на первичном кластере обнаруживает конфликты, она вставляет события в свой собственный двоичный журнал, чтобы компенсировать их; это гарантирует, что вторичный кластер NDB в конечном итоге выровняется с первичным, и таким образом предотвращает расхождение первичного и вторичного кластеров. Этот механизм компенсации и выравнивания требует, чтобы первичный кластер NDB всегда выигрывал любые конфликты со вторичным, то есть, что изменения первичного кластера всегда используются вместо изменений со вторичного в случае конфликта. Это правило “первичный всегда выигрывает” имеет следующие последствия:

NDB$EPOCH() и NDB$EPOCH_TRANS() не требуют никаких изменений схемы пользователя или приложений для обнаружения конфликтов. Однако необходимо тщательно продумать используемую схему и шаблоны доступа, чтобы убедиться, что вся система функционирует в заданных пределах.

Каждая из функций NDB$EPOCH() и NDB$EPOCH_TRANS() может принимать необязательный параметр; это количество битов, используемых для представления младших 32 битов эпохи, и должно быть не меньше значения, рассчитанного, как показано здесь:

CEIL( LOG2( TimeBetweenGlobalCheckpoints / TimeBetweenEpochs ), 1)

Для значений по умолчанию этих параметров конфигурации (2000 и 100 миллисекунд соответственно) это дает значение 5 битов, поэтому значение по умолчанию (6) должно быть достаточным, если не используются другие значения для TimeBetweenGlobalCheckpoints, TimeBetweenEpochs или обоих. Слишком маленькое значение может привести к ложным срабатываниям, а слишком большое — к чрезмерному расходу места в базе данных.

Обе функции NDB$EPOCH() и NDB$EPOCH_TRANS() вставляют записи для конфликтующих строк в соответствующие таблицы исключений, при условии, что эти таблицы определены в соответствии с теми же правилами схемы таблиц исключений, что описаны в другом разделе (см. NDB$OLD()). Вы должны создать таблицу исключений перед созданием таблицы данных, с которой она будет использоваться.

Как и другие функции обнаружения конфликтов, обсуждаемые в этом разделе, функции NDB$EPOCH() и NDB$EPOCH_TRANS() активируются путем включения соответствующих записей в таблицу mysql.ndb_replication (см. таблицу ndb_replication). Роли первичного и вторичного кластеров NDB в этом сценарии полностью определяются записями в таблице mysql.ndb_replication.

Поскольку алгоритмы обнаружения конфликтов, используемые функциями NDB$EPOCH() и NDB$EPOCH_TRANS(), асимметричны, вы должны использовать разные значения для записей server_id первичной и вторичной реплик.

Конфликт только операций DELETE недостаточно для активации конфликта с помощью функций NDB$EPOCH() или NDB$EPOCH_TRANS(), и относительное расположение в эпохах не имеет значения.

Ограничения NDB$EPOCH()

Следующие ограничения в настоящее время применяются при использовании функции NDB$EPOCH() для обнаружения конфликтов:

NDB$EPOCH_TRANS()

NDB$EPOCH_TRANS() расширяет функцию NDB$EPOCH(). Конфликты обнаруживаются и обрабатываются аналогично, используя правило «первичный узел выигрывает во всем» (см. NDB$EPOCH()), но с дополнительным условием, что все другие строки, обновленные в той же транзакции, в которой произошел конфликт, также считаются находящимися в конфликте. Другими словами, где функция NDB$EPOCH() выравнивает отдельные конфликтующие строки на вторичном узле, функция NDB$EPOCH_TRANS() выравнивает конфликтующие транзакции.

Кроме того, все транзакции, которые, как можно обнаружить, зависят от конфликтующей транзакции, также считаются находящимися в конфликте, эти зависимости определяются содержимым двоичного журнала вторичного кластера. Поскольку двоичный журнал содержит только операции изменения данных (вставки, обновления и удаления), только перекрывающиеся изменения данных используются для определения зависимостей между транзакциями.

NDB$EPOCH_TRANS() подчиняется тем же условиям и ограничениям, что и NDB$EPOCH(), а также требует, чтобы все идентификаторы транзакций записывались в двоичный журнал вторичного кластера, используя --ndb-log-transaction-id установленным в значение ON. Это добавляет переменную нагрузку (до 13 байтов на строку).

См. NDB$EPOCH().

NDB$EPOCH2()

Функция NDB$EPOCH2() похожа на функцию NDB$EPOCH(), за исключением того, что NDB$EPOCH2() предоставляет обработку удаления-удаления с двунаправленной топологией репликации. В этом случае роли первичного и вторичного узла для двух источников назначаются путем установки системной переменной ndb_conflict_role в соответствующее значение на каждом источнике (обычно один для PRIMARY, SECONDARY). При выполнении этого действия изменения, внесенные вторичным узлом, отражаются первичным узлом обратно на вторичный, который затем условно их применяет.

NDB$EPOCH2_TRANS()

NDB$EPOCH2_TRANS() расширяет функцию NDB$EPOCH2(). Конфликты обнаруживаются и обрабатываются аналогично, и роли первичного и вторичного узла для реплицируемых кластеров назначаются, но с дополнительным условием, что все другие строки, обновленные в той же транзакции, в которой произошел конфликт, также считаются находящимися в конфликте. То есть, функция NDB$EPOCH2() выравнивает отдельные конфликтующие строки на вторичном узле, а функция NDB$EPOCH_TRANS() выравнивает конфликтующие транзакции.

Функции NDB$EPOCH() и NDB$EPOCH_TRANS() используют метаданные, указанные для каждой строки, каждой последней измененной эпохи, чтобы определить на первичном узле, является ли входящее скопированное изменение строки со вторичного узла одновременным с локально зафиксированным изменением; одновременные изменения считаются конфликтующими, с последующими обновлениями таблиц исключений и выравниванием вторичного узла. Проблема возникает, когда строка удаляется на первичном узле, так что последняя измененная эпоха больше недоступна для определения, конфликтуют ли какие-либо скопированные операции, что означает, что конфликтующие операции удаления не обнаруживаются. Это может привести к расхождению, примером может служить удаление на одном кластере, одновременное с удалением и вставкой на другом; вот почему операции удаления могут направляться только на один кластер при использовании функций NDB$EPOCH() и NDB$EPOCH_TRANS().

Функция NDB$EPOCH2() обходит эту проблему — сохранение информации об удаленных строках на ПЕРВИЧНОМ узле — путем игнорирования конфликтов удаление-удаление и избежания возможного расхождения. Это достигается путем отражения любой операции, успешно примененной и скопированной со вторичного узла обратно на вторичный узел. При возвращении на вторичный узел она может использоваться для повторного применения операции на вторичном узле, которая была удалена операцией, исходящей с первичного узла.

При использовании NDB$EPOCH2(), следует учитывать, что вторичный сервер применяет удаление из первичного, удаляя новую строку до тех пор, пока она не будет восстановлена отражённой операцией. Теоретически, последующая вставка или обновление на вторичном сервере конфликтует с удалением из первичного, но в этом случае мы предпочитаем игнорировать это и позволить вторичному серверу “победить” в целях предотвращения расхождений между кластерами. Другими словами, после удаления первичный сервер не обнаруживает конфликтов и вместо этого сразу же принимает последующие изменения вторичного сервера. Из-за этого состояние вторичного сервера может возвращаться к нескольким предыдущим сохранённым состояниям по мере продвижения к конечному (стабильному) состоянию, и некоторые из них могут быть видимы.

Также следует помнить, что отражение всех операций со вторичного сервера на первичный увеличивает размер журнала первичного сервера logbinary log, а также требует увеличения пропускной способности, использования ЦП и ввода-вывода на диск.

Применение отражённых операций на вторичном сервере зависит от состояния целевой строки на вторичном сервере. Можно отслеживать применение или неприменение отражённых изменений на вторичном сервере, проверяя переменные состояния Ndb_conflict_reflected_op_prepare_count и Ndb_conflict_reflected_op_discard_count. Количество применённых изменений просто равно разнице между этими двумя значениями (обратите внимание, что Ndb_conflict_reflected_op_prepare_count всегда больше или равно Ndb_conflict_reflected_op_discard_count).

События применяются только в том случае, если оба следующих условия верны:

Если оба этих условия не выполнены, вторичный сервер отбрасывает отражённую операцию.

В следующих примерах предполагается, что у вас уже настроено реплицирование кластера NDB, как описано в разделе 25.7.5, «Подготовка кластера NDB к реплицированию», и разделе 25.7.6, «Запуск реплицирования кластера NDB (один канал репликации)».

Пример NDB$MAX(). Предположим, вы хотите включить механизм разрешения конфликтов «наибольшая метка времени выигрывает» для таблицы test.t1, используя столбец mycol в качестве метки времени. Это можно сделать, выполнив следующие шаги:

Пример NDB$OLD(). Предположим, что реплицируется таблица NDB (такой, как определенная здесь), и вы хотите включить механизм разрешения конфликтов «то же значение метки времени выигрывает» для обновлений этой таблицы:

CREATE TABLE test.t2  (
    a INT UNSIGNED NOT NULL,
    b CHAR(25) NOT NULL,
    columns,
    mycol INT UNSIGNED NOT NULL,
    columns,
    PRIMARY KEY pk (a, b)
)   ENGINE=NDB;

Необходимы следующие шаги в указанном порядке:

Эти шаги должны выполняться для каждой таблицы, для которой вы хотите использовать разрешение конфликтов с помощью NDB$OLD(). Для каждой такой таблицы должна быть соответствующая строка в mysql.ndb_replication, а таблица исключений должна находиться в той же базе данных, что и реплицируемая таблица.

Пример обнаружения и разрешения конфликтов при чтении. Кластер NDB также поддерживает отслеживание операций чтения, что позволяет управлять конфликтами между чтением определенной строки в одном кластере и обновлениями или удалениями этой же строки в другом кластере в установках циклической репликации. В этом примере используются таблицы employee и department для моделирования сценария, в котором сотрудник перемещается из одного отдела в другой в исходном кластере (который мы далее будем обозначать как кластер A), в то время как реплицирующий кластер (далее B) обновляет количество сотрудников в прежнем отделе сотрудника в перекрывающейся транзакции.

Таблицы данных были созданы с помощью следующих операторов SQL:

# Employee table
CREATE TABLE employee (
    id INT PRIMARY KEY,
    name VARCHAR(2000),
    dept INT NOT NULL
)   ENGINE=NDB;

# Department table
CREATE TABLE department (
    id INT PRIMARY KEY,
    name VARCHAR(2000),
    members INT
)   ENGINE=NDB;

Содержание двух таблиц включает строки, показанные в (частичном) выводе следующих операторов SELECT:

mysql> SELECT id, name, dept FROM employee;
+---------------+------+
| id   | name   | dept |
+------+--------+------+
...
| 998  |  Mike  | 3    |
| 999  |  Joe   | 3    |
| 1000 |  Mary  | 3    |
...
+------+--------+------+

mysql> SELECT id, name, members FROM department;
+-----+-------------+---------+
| id  | name        | members |
+-----+-------------+---------+
...
| 3   | Old project | 24      |
...
+-----+-------------+---------+

Мы предполагаем, что мы уже используем таблицу исключений, которая включает четыре необходимых столбца (и эти столбцы используются для первичного ключа этой таблицы), дополнительные столбцы для типа операции и причины, а также столбец первичного ключа исходной таблицы, созданный с помощью показанного здесь оператора SQL:

CREATE TABLE employee$EX  (
    NDB$server_id INT UNSIGNED,
    NDB$source_server_id INT UNSIGNED,
    NDB$source_epoch BIGINT UNSIGNED,
    NDB$count INT UNSIGNED,

    NDB$OP_TYPE ENUM( 'WRITE_ROW','UPDATE_ROW', 'DELETE_ROW',
                      'REFRESH_ROW','READ_ROW') NOT NULL,
    NDB$CFT_CAUSE ENUM( 'ROW_DOES_NOT_EXIST',
                        'ROW_ALREADY_EXISTS',
                        'DATA_IN_CONFLICT',
                        'TRANS_IN_CONFLICT') NOT NULL,

    id INT NOT NULL,

    PRIMARY KEY(NDB$server_id, NDB$source_server_id, NDB$source_epoch, NDB$count)
)   ENGINE=NDB;

Предположим, что на двух кластерах произошли две одновременные транзакции. В кластере A мы создаём новый отдел, затем перемещаем сотрудника с номером 999 в этот отдел, используя следующие операторы SQL:

BEGIN;
  INSERT INTO department VALUES (4, "New project", 1);
  UPDATE employee SET dept = 4 WHERE id = 999;
COMMIT;

В то же время, в кластере B, другая транзакция считывает данные из employee, как показано здесь:

BEGIN;
  SELECT name FROM employee WHERE id = 999;
  UPDATE department SET members = members - 1  WHERE id = 3;
commit;

Обычно механизм разрешения конфликтов не обнаруживает конфликтующие транзакции, поскольку конфликт происходит между операцией чтения (SELECT) и операцией обновления. Вы можете обойти эту проблему, выполнив оператор SET ndb_log_exclusive_reads = 1 в реплицирующем кластере. Приобретение эксклюзивных блокировок чтения таким образом приводит к тому, что любые строки, прочитанные на источнике, отмечаются как требующие разрешения конфликтов в реплицирующем кластере. Если мы включим эксклюзивные чтения таким образом до журналирования этих транзакций, чтение в кластере B отслеживается и отправляется в кластер A для разрешения; конфликт в строке сотрудника впоследствии обнаруживается, и транзакция в кластере B прерывается.

Конфликт регистрируется в таблице исключений (в кластере A) как операция READ_ROW (см. таблицу исключений разрешения конфликтов для описания типов операций), как показано здесь:

mysql> SELECT id, NDB$OP_TYPE, NDB$CFT_CAUSE FROM employee$EX;
+-------+-------------+-------------------+
| id    | NDB$OP_TYPE | NDB$CFT_CAUSE     |
+-------+-------------+-------------------+
...
| 999   | READ_ROW    | TRANS_IN_CONFLICT |
+-------+-------------+-------------------+

Любые существующие строки, найденные в операции чтения, помечаются. Это означает, что несколько строк, являющихся результатом одного и того же конфликта, могут быть залогированы в таблице исключений, как показано при исследовании последствий конфликта между обновлением в кластере A и чтением нескольких строк в кластере B из одной и той же таблицы в одновременных транзакциях. Транзакция, выполненная в кластере A, показана здесь:

BEGIN;
  INSERT INTO department VALUES (4, "New project", 0);
  UPDATE employee SET dept = 4 WHERE dept = 3;
  SELECT COUNT(*) INTO @count FROM employee WHERE dept = 4;
  UPDATE department SET members = @count WHERE id = 4;
COMMIT;

Одновременно в кластере B выполняется транзакция с операторами, показанными здесь:

SET ndb_log_exclusive_reads = 1;  # Must be set if not already enabled
...
BEGIN;
  SELECT COUNT(*) INTO @count FROM employee WHERE dept = 3 FOR UPDATE;
  UPDATE department SET members = @count WHERE id = 3;
COMMIT;

В этом случае все три строки, соответствующие условию WHERE в операторе чтения второй транзакции, читаются и помечаются в таблице исключений, как показано здесь:

mysql> SELECT id, NDB$OP_TYPE, NDB$CFT_CAUSE FROM employee$EX;
+-------+-------------+-------------------+
| id    | NDB$OP_TYPE | NDB$CFT_CAUSE     |
+-------+-------------+-------------------+
...
| 998   | READ_ROW    | TRANS_IN_CONFLICT |
| 999   | READ_ROW    | TRANS_IN_CONFLICT |
| 1000  | READ_ROW    | TRANS_IN_CONFLICT |
...
+-------+-------------+-------------------+

Отслеживание чтения выполняется только на основе существующих строк. Чтение, основанное на заданном условии, отслеживает конфликты только тех строк, которые находятся, а не тех, которые вставлены в перекрывающуюся транзакцию. Это аналогично тому, как выполняется эксклюзивное блокирование строк в одном экземпляре кластера NDB.

Пример обнаружения и разрешения конфликтов при вставке. Следующий пример иллюстрирует использование функций обнаружения конфликтов при вставке. Мы предполагаем, что мы реплицируем две таблицы t1 и t2 в базе данных test, и что мы хотим использовать обнаружение конфликтов при вставке с помощью NDB$MAX_INS() для t1 и NDB$MAX_DEL_WIN_INS() для t2. Две таблицы данных создаются позднее в процессе настройки.

Настройка разрешения конфликтов при вставке аналогична настройке других алгоритмов обнаружения и разрешения конфликтов, как показано в предыдущих примерах. Если таблица mysql.ndb_replication, используемая для настройки двоичного журналирования и разрешения конфликтов, еще не существует, необходимо сначала создать ее, как показано здесь:

CREATE TABLE mysql.ndb_replication (
    db VARBINARY(63),
    table_name VARBINARY(63),
    server_id INT UNSIGNED,
    binlog_type INT UNSIGNED,
    conflict_fn VARBINARY(128),
    PRIMARY KEY USING HASH (db, table_name, server_id)
) ENGINE=NDB
PARTITION BY KEY(db,table_name);

Таблица ndb_replication действует на основе каждой таблицы; то есть, нам необходимо вставить строку, содержащую информацию о таблице, значение binlog_type, функцию разрешения конфликтов, которая должна быть применена, и имя столбца отметки времени (X) для каждой устанавливаемой таблицы, например так:

INSERT INTO mysql.ndb_replication VALUES ("test", "t1", 0, 7, "NDB$MAX_INS(X)");
INSERT INTO mysql.ndb_replication VALUES ("test", "t2", 0, 7, "NDB$MAX_DEL_WIN_INS(X)");

Здесь мы установили binlog_type как NBT_FULL_USE_UPDATE (7), что означает, что полные строки всегда регистрируются. Смотрите таблицу ndb_replication для других возможных значений.

Вы также можете создать таблицу исключений, соответствующую каждой таблице NDB, для которой необходимо использовать разрешение конфликтов. Таблица исключений записывает все строки, отклоненные функцией разрешения конфликтов для данной таблицы. Таблицы исключений для обнаружения конфликтов при репликации для таблиц t1 и t2 могут быть созданы с помощью следующих двух SQL-запросов:

CREATE TABLE `t1$EX` (
    NDB$server_id INT UNSIGNED,
    NDB$source_server_id INT UNSIGNED,
    NDB$source_epoch BIGINT UNSIGNED,
    NDB$count INT UNSIGNED,
    NDB$OP_TYPE ENUM('WRITE_ROW', 'UPDATE_ROW', 'DELETE_ROW',
                     'REFRESH_ROW', 'READ_ROW') NOT NULL,
    NDB$CFT_CAUSE ENUM('ROW_DOES_NOT_EXIST', 'ROW_ALREADY_EXISTS',
                       'DATA_IN_CONFLICT', 'TRANS_IN_CONFLICT') NOT NULL,
    a INT NOT NULL,
    PRIMARY KEY(NDB$server_id, NDB$source_server_id,
                NDB$source_epoch, NDB$count)
) ENGINE=NDB;

CREATE TABLE `t2$EX` (
    NDB$server_id INT UNSIGNED,
    NDB$source_server_id INT UNSIGNED,
    NDB$source_epoch BIGINT UNSIGNED,
    NDB$count INT UNSIGNED,
    NDB$OP_TYPE ENUM('WRITE_ROW', 'UPDATE_ROW', 'DELETE_ROW',
                     'REFRESH_ROW', 'READ_ROW') NOT NULL,
    NDB$CFT_CAUSE ENUM( 'ROW_DOES_NOT_EXIST', 'ROW_ALREADY_EXISTS',
                        'DATA_IN_CONFLICT', 'TRANS_IN_CONFLICT') NOT NULL,
    a INT NOT NULL,
    PRIMARY KEY(NDB$server_id, NDB$source_server_id,
                NDB$source_epoch, NDB$count)
) ENGINE=NDB;

Наконец, после создания только что показанных таблиц исключений, вы можете создать таблицы данных, которые должны быть реплицированы и подлежат контролю разрешения конфликтов, используя следующие два SQL-запроса:

CREATE TABLE t1 (
    a INT PRIMARY KEY,
    b VARCHAR(32),
    X INT UNSIGNED
) ENGINE=NDB;

CREATE TABLE t2 (
    a INT PRIMARY KEY,
    b VARCHAR(32),
    X INT UNSIGNED
) ENGINE=NDB;

Для каждой таблицы столбец X используется в качестве столбца отметки времени.

После создания на источнике t1 и t2 реплицируются и могут считаться существующими как на источнике, так и на реплике. В оставшейся части этого примера мы используем mysqlS> для обозначения подключенного к источнику клиента mysql, и mysqlR> для обозначения работающего на реплике клиента mysql.

Сначала мы вставляем по одной строке в каждую таблицу на источнике, так:

mysqlS> INSERT INTO t1 VALUES (1, 'Initial X=1', 1);
Query OK, 1 row affected (0.01 sec)

mysqlS> INSERT INTO t2 VALUES (1, 'Initial X=1', 1);
Query OK, 1 row affected (0.01 sec)

Мы можем быть уверены, что эти две строки реплицируются без возникновения каких-либо конфликтов, так как таблицы на реплике не содержали строк до выполнения инструкций INSERT на источнике. Мы можем проверить это, выбрав из таблиц на реплике, как показано здесь:

mysqlR> TABLE t1 ORDER BY a;
+---+-------------+------+
| a | b           | X    |
+---+-------------+------+
| 1 | Initial X=1 |    1 |
+---+-------------+------+
1 row in set (0.00 sec)

mysqlR> TABLE t2 ORDER BY a;
+---+-------------+------+
| a | b           | X    |
+---+-------------+------+
| 1 | Initial X=1 |    1 |
+---+-------------+------+
1 row in set (0.00 sec)

Далее, мы вставляем новые строки в таблицы на реплике, как показано здесь:

mysqlR> INSERT INTO t1 VALUES (2, 'Replica X=2', 2);
Query OK, 1 row affected (0.01 sec)

mysqlR> INSERT INTO t2 VALUES (2, 'Replica X=2', 2);
Query OK, 1 row affected (0.01 sec)

Теперь мы вставляем конфликтные строки в таблицы на источнике, имеющие большие значения столбца отметки времени (X), используя представленные здесь инструкции:

mysqlS> INSERT INTO t1 VALUES (2, 'Replica X=20', 20);
Query OK, 1 row affected (0.01 sec)

mysqlS> INSERT INTO t2 VALUES (2, 'Replica X=20', 20);
Query OK, 1 row affected (0.01 sec)

Теперь мы наблюдаем результаты, выбирая (снова) из обеих таблиц на реплике, как показано здесь:

mysqlR> TABLE t1 ORDER BY a;
+---+-------------+-------+
| a | b           | X     |
+---+-------------+-------+
| 1 | Initial X=1 |    1  |
+---+-------------+-------+
| 2 | Source X=20 |   20  |
+---+-------------+-------+
2 rows in set (0.00 sec)

mysqlR> TABLE t2 ORDER BY a;
+---+-------------+-------+
| a | b           | X     |
+---+-------------+-------+
| 1 | Initial X=1 |    1  |
+---+-------------+-------+
| 1 | Source X=20 |   20  |
+---+-------------+-------+
2 rows in set (0.00 sec)

Строки, вставленные на источнике, имеющие большие отметки времени, чем строки в конфликтных строках на реплике, заменили эти строки. На реплике мы затем вставляем две новые строки, которые не конфликтуют с никакими существующими строками в t1 или t2, как показано здесь:

mysqlR> INSERT INTO t1 VALUES (3, 'Replica X=30', 30);
Query OK, 1 row affected (0.01 sec)

mysqlR> INSERT INTO t2 VALUES (3, 'Replica X=30', 30);
Query OK, 1 row affected (0.01 sec)

Вставка дополнительных строк на источнике с тем же значением первичного ключа (3) вызывает конфликты, как и прежде, но на этот раз мы используем значение для столбца отметки времени меньше, чем в том же столбце в конфликтных строках на реплике.

mysqlS> INSERT INTO t1 VALUES (3, 'Source X=3', 3);
Query OK, 1 row affected (0.01 sec)

mysqlS> INSERT INTO t2 VALUES (3, 'Source X=3', 3);
Query OK, 1 row affected (0.01 sec)

Мы можем видеть, выполняя запросы к таблицам, что обе вставки с источника были отклонены репликой, и строки, вставленные на реплике ранее, не были перезаписаны, как показано здесь в клиенте mysql на реплике:

mysqlR> TABLE t1 ORDER BY a;
+---+--------------+-------+
| a | b            | X     |
+---+--------------+-------+
| 1 |  Initial X=1 |    1  |
+---+--------------+-------+
| 2 |  Source X=20 |   20  |
+---+--------------+-------+
| 3 | Replica X=30 |   30  |
+---+--------------+-------+
3 rows in set (0.00 sec)

mysqlR> TABLE t2 ORDER BY a;
+---+--------------+-------+
| a | b            | X     |
+---+--------------+-------+
| 1 |  Initial X=1 |    1  |
+---+--------------+-------+
| 2 |  Source X=20 |   20  |
+---+--------------+-------+
| 3 | Replica X=30 |   30  |
+---+--------------+-------+
3 rows in set (0.00 sec)

Вы можете увидеть информацию о строках, которые были отклонены, в таблицах исключений, как показано здесь:

mysqlR> SELECT  NDB$server_id, NDB$source_server_id, NDB$count,
      >         NDB$OP_TYPE, NDB$CFT_CAUSE, a
      > FROM t1$EX
      > ORDER BY NDB$count\G
*************************** 1. row ***************************
NDB$server_id       : 2
NDB$source_server_id: 1
NDB$count           : 1
NDB$OP_TYPE         : WRITE_ROW
NDB$CFT_CAUSE       : DATA_IN_CONFLICT
a                   : 3
1 row in set (0.00 sec)

mysqlR> SELECT  NDB$server_id, NDB$source_server_id, NDB$count,
      >         NDB$OP_TYPE, NDB$CFT_CAUSE, a
      > FROM t2$EX
      > ORDER BY NDB$count\G
*************************** 1. row ***************************
NDB$server_id       : 2
NDB$source_server_id: 1
NDB$count           : 1
NDB$OP_TYPE         : WRITE_ROW
NDB$CFT_CAUSE       : DATA_IN_CONFLICT
a                   : 3
1 row in set (0.00 sec)

Как мы видели ранее, никакие другие строки, вставленные на источнике, не были отклонены репликой, только те строки, которые имели меньшее значение отметки времени, чем строки в конфликте на реплике.