В этом разделе представлена подробная информация о функциях, которые могут использоваться для обнаружения и разрешения конфликтов с репликацией 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, а также требует большей пропускной способности, использования ЦП и ввода-вывода на диск.

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

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

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

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

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

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

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 во второй транзакции, SELECT, читаются, и поэтому помечаются в таблице исключений, как показано здесь:

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)

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