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

В отличие от таблиц ndb_apply_status и ndb_replication, таблицу ndb_replication необходимо создавать вручную, используя представленное здесь SQL-утверждение:

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

Таблица ndb_replication позволяет контролировать протоколирование на уровне таблиц вне сферы разрешения конфликтов, в этом случае conflict_fn задается как NULL, а оставшиеся значения столбцов используются для управления двоичным протоколированием для данной таблицы или набора таблиц, соответствующих выражению с подстановкой. Установив соответствующее значение в столбце binlog_type, вы можете настроить протоколирование для заданной таблицы или таблиц на желаемый формат двоичного протоколирования или полностью отключить двоичное протоколирование. Возможные значения для этого столбца с значениями и описаниями показаны в следующей таблице:

Несколько значений binlog_type эквивалентны различным комбинациям параметров протоколирования mysqld --ndb-log-updated-only, --ndb-log-update-as-write и --ndb-log-update-minimal, как показано в следующей таблице:

Двоичное протоколирование может быть настроено на разные форматы для разных таблиц путем вставки строк в таблицу ndb_replication с соответствующими значениями столбцов db, table_name и binlog_type. Внутреннее целое значение, показанное в предыдущей таблице, следует использовать при настройке формата двоичного протоколирования. Следующие два утверждения настраивают двоичное протоколирование на протоколирование полных строк (значение 3) для таблицы test.a и на протоколирование только обновлений (значение 2) для таблицы test.b:

# Table test.a: Log full rows
INSERT INTO mysql.ndb_replication VALUES("test", "a", 0, 3, NULL);

# Table test.b: log updates only
INSERT INTO mysql.ndb_replication VALUES("test", "b", 0, 2, NULL);

Для отключения протоколирования для одной или нескольких таблиц используйте 1 для binlog_type, как показано здесь:

# Disable binary logging for table test.t1
INSERT INTO mysql.ndb_replication VALUES("test", "t1", 0, 1, NULL);

# Disable binary logging for any table in 'test' whose name begins with 't'
INSERT INTO mysql.ndb_replication VALUES("test", "t%", 0, 1, NULL);

Отключение протоколирования для заданной таблицы эквивалентно установке sql_log_bin = 0, за исключением того, что это применяется к одной или нескольким таблицам индивидуально. Если узел SQL не выполняет двоичное протоколирование для заданной таблицы, он не получает события изменения строки для этих таблиц. Это означает, что он не получает все изменения и отбрасывает некоторые, а не подписывается на эти изменения.

Отключение протоколирования может быть полезным по ряду причин, включая перечисленные здесь:

Сопоставление с подстановками. Для того, чтобы не было необходимости вставлять строку в таблицу ndb_replication для каждой комбинации базы данных, таблицы и SQL-узла в вашей настройке репликации, NDB поддерживает сопоставление по шаблонам в столбцах этой таблицы db, table_name и server_id. Имена баз данных и таблиц, используемые в db и table_name соответственно, могут содержать один или оба из следующих шаблонов:

(Это те же подстановки, что и в операторе MySQL LIKE.)

Столбец server_id поддерживает 0 в качестве подстановки, эквивалентной _ (соответствует любому значению). Это используется в примерах, показанных ранее.

Определённая строка в таблице ndb_replication может использовать подстановки для сопоставления имени базы данных, имени таблицы и идентификатора сервера в любой комбинации. Если в таблице существует несколько потенциальных совпадений, выбирается наилучшее совпадение в соответствии с представленной здесь таблицей, где W представляет подстановку, E — точное совпадение, а чем больше значение в столбце Quality, тем лучше совпадение:

Таким образом, точное совпадение имени базы данных, имени таблицы и идентификатора сервера считается наилучшим (наиболее сильным), а наименее сильным (худшим) совпадением является подстановка во всех трёх столбцах. При выборе правила для применения учитывается только сила совпадения; порядок строк в таблице не влияет на это определение.

Регистрация полных или частичных строк. Существуют два основных метода регистрации строк, определяемых значением параметра --ndb-log-updated-only для mysqld:

Обычно достаточно (и эффективнее) регистрировать только обновлённые столбцы; однако, если вам необходимо регистрировать полные строки, вы можете сделать это, установив --ndb-log-updated-only на 0 или OFF.

Регистрация изменённых данных как обновлений. Настройка параметра MySQL Server --ndb-log-update-as-write определяет, выполняется ли регистрация с или без изображения “before”.

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

Этот параметр включён по умолчанию; другими словами, обновления обрабатываются как записи. То есть, обновления по умолчанию записываются как write_row-события в двоичном логе, а не как update_row-события.

Чтобы отключить этот параметр, запустите исходный mysqld с --ndb-log-update-as-write=0 или --ndb-log-update-as-write=OFF. Это необходимо при репликации из NDB-таблиц в таблицы, использующие другой движок хранения; см. Репликация из NDB в другие движки хранения и Репликация из NDB в нетранзакционный движок хранения для получения дополнительной информации.