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

При использовании функций NDB$OLD(), NDB$MAX() и NDB$MAX_DELETE_WIN() для разрешения конфликтов на основе временных меток, мы часто называем колонку, используемую для определения обновлений, колонкой “временная метка”. Однако тип данных этой колонки никогда не является TIMESTAMP; вместо этого её тип данных должен быть INT (INTEGER) или BIGINT. Колонку “временная метка” также следует UNSIGNED и NOT NULL.

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

Мы можем рассматривать операции обновления с точки зрения “до” и “после” изображений — то есть состояний таблицы до и после применения обновления. Обычно при обновлении таблицы с первичным ключом изображение “до” не представляет большого интереса; однако, когда нам нужно определить, следует ли использовать обновлённые значения на реплике на основе каждого обновления, нам нужно убедиться, что оба изображения записываются в двоичный журнал источника. Это делается с помощью опции --ndb-log-update-as-write для mysqld, как описано далее в этом разделе.

Разрешение конфликтов обычно включено на сервере, где могут возникнуть конфликты. Как и выбор метода ведения журнала, это включается записями в таблице mysql.ndb_replication.

NBT_UPDATED_ONLY_MINIMAL и NBT_UPDATED_FULL_MINIMAL могут использоваться с NDB$EPOCH(), NDB$EPOCH2() и NDB$EPOCH_TRANS(), так как для этого не нужны значения колонок «до» не являющиеся первичными ключами. Алгоритмы разрешения конфликтов, требующие старых значений, такие как NDB$MAX() и NDB$OLD(), не работают правильно с этими значениями binlog_type.

Для использования функции разрешения конфликтов NDB$OLD() также необходимо создать таблицу исключений, соответствующую каждой таблице NDB, для которой этот тип разрешения конфликтов будет применяться. Это также справедливо при использовании NDB$EPOCH() или NDB$EPOCH_TRANS(). Название этой таблицы — название таблицы, к которой применяется разрешение конфликтов, с добавленной строкой $EX. (Например, если имя исходной таблицы — mytable, имя соответствующей таблицы исключений должно быть mytable$EX.) Синтаксис создания таблицы исключений показан ниже:

CREATE TABLE original_table$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,]
    [NDB$ORIG_TRANSID BIGINT UNSIGNED NOT NULL,]

    original_table_pk_columns,

    [orig_table_column|orig_table_column$OLD|orig_table_column$NEW,]

    [additional_columns,]

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

Первые четыре столбца являются обязательными. Имена первых четырех столбцов и столбцов, соответствующих столбцам первичного ключа исходной таблицы, не являются критическими; однако, для ясности и согласованности рекомендуется использовать показанные здесь имена для столбцов server_id, source_server_id, source_epoch и count и те же имена, что и в исходной таблице, для столбцов, соответствующих столбцам первичного ключа исходной таблицы.

Если таблица исключений использует один или несколько необязательных столбцов NDB$OP_TYPE, NDB$CFT_CAUSE или NDB$ORIG_TRANSID, обсуждаемых позже в этом разделе, то каждое из требуемых столбцов также должно быть названо с префиксом NDB$. При желании вы можете использовать префикс NDB$ для именования обязательных столбцов, даже если вы не определяете никаких необязательных столбцов, но в этом случае все четыре обязательных столбца должны быть названы с использованием этого префикса.

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

Таблица исключений должна использовать хранилище NDB. (Пример использования NDB$OLD() с таблицей исключений показан позже в этом разделе.)

Дополнительные столбцы могут быть определены необязательно после скопированных столбцов первичного ключа, но не перед ними; любые такие дополнительные столбцы не могут быть NOT NULL. NDB Cluster поддерживает три дополнительных предопределенных необязательных столбца NDB$OP_TYPE, NDB$CFT_CAUSE и NDB$ORIG_TRANSID, которые описаны в следующих нескольких абзацах.

NDB$OP_TYPE: Этот столбец может быть использован для получения типа операции, вызвавшей конфликт. Если вы используете этот столбец, определите его следующим образом:

NDB$OP_TYPE ENUM('WRITE_ROW', 'UPDATE_ROW', 'DELETE_ROW',
    'REFRESH_ROW', 'READ_ROW') NOT NULL

Типы операций WRITE_ROW, UPDATE_ROW и DELETE_ROW представляют операции, инициированные пользователем. Операции REFRESH_ROW — это операции, сгенерированные разрешением конфликтов в компенсирующих транзакциях, отправленных обратно в исходный кластер из кластера, обнаружившего конфликт. Операции READ_ROW — это операции отслеживания чтения, инициированные пользователем, определённые с эксклюзивными блокировками строк.

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

NDB$CFT_CAUSE ENUM('ROW_DOES_NOT_EXIST', 'ROW_ALREADY_EXISTS',
    'DATA_IN_CONFLICT', 'TRANS_IN_CONFLICT') NOT NULL

ROW_DOES_NOT_EXIST может быть указан как причина для операций UPDATE_ROW и WRITE_ROW; ROW_ALREADY_EXISTS может быть указан для событий WRITE_ROW. DATA_IN_CONFLICT указывается, когда функция конфликта на основе строк обнаруживает конфликт; TRANS_IN_CONFLICT указывается, когда функция конфликта транзакций отклоняет все операции, принадлежащие к полной транзакции.

NDB$ORIG_TRANSID: Столбец NDB$ORIG_TRANSID, если используется, содержит идентификатор исходной транзакции. Этот столбец должен быть определён следующим образом:

NDB$ORIG_TRANSID BIGINT UNSIGNED NOT NULL

NDB$ORIG_TRANSID — это 64-битовое значение, сгенерированное NDB. Это значение может быть использовано для сопоставления нескольких записей в таблице исключений, принадлежащих одной и той же конфликтной транзакции из одной и той же или разных таблиц исключений.

Дополнительные столбцы ссылок, которые не являются частью первичного ключа исходной таблицы, могут быть названы colname$OLD или colname$NEW. colname$OLD ссылается на старые значения в операциях обновления и удаления — то есть операциях, содержащих события DELETE_ROW. colname$NEW может использоваться для ссылки на новые значения в операциях вставки и обновления — другими словами, операциях, использующих события WRITE_ROW, события UPDATE_ROW или оба типа событий. Если конфликтная операция не предоставляет значение для данного столбца ссылки, который не является первичным ключом, строка таблицы исключений содержит либо NULL, либо определённое значение по умолчанию для этого столбца.

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

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

Другая переменная состояния сервера Ndb_conflict_fn_max предоставляет счётчик количества раз, когда строка не была применена на текущем узле SQL из-за конфликта “самый большой временной отметки выигрывает” с момента последнего запуска mysqld. Ndb_conflict_fn_max_del_win предоставляет счётчик количества раз, когда разрешение конфликтов, основанное на результате NDB$MAX_DELETE_WIN(), было применено.

Количество раз, когда строка не была применена в результате конфликта “та же временная отметка выигрывает” на данном узле mysqld с момента последнего его перезапуска, задаётся глобальной переменной состояния Ndb_conflict_fn_old. Кроме инкрементирования Ndb_conflict_fn_old, первичный ключ строки, которая не была использована, вставляется в таблицу исключений, как объясняется в другом месте этого раздела.

См. также Раздел 21.4.3.9.3, «Переменные состояния NDB Cluster».

В следующих примерах предполагается, что у вас уже настроено работающее реплицирование NDB кластера, как описано в разделе 21.7.5, «Подготовка NDB кластера к репликации», и разделе 21.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 Cluster также поддерживает отслеживание операций чтения, что позволяет в конфигурациях циклической репликации управлять конфликтами между чтением заданной строки в одном кластере и обновлением или удалением этой же строки в другом. В этом примере используются таблицы 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 Cluster.