ndb_apply_status用于记录已从源复制到副本的操作。如果该ndb_apply_status表在副本上不存在，ndb_restore 会重新创建它。

与 的情况不同ndb_binlog_index，此表中的数据不特定于（副本）集群中的任何一个 SQL 节点，因此ndb_apply_status 可以使用NDBCLUSTER存储引擎，如下所示：

CREATE TABLE `ndb_apply_status` (
    `server_id`   INT(10) UNSIGNED NOT NULL,
    `epoch`       BIGINT(20) UNSIGNED NOT NULL,
    `log_name`    VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
    `start_pos`   BIGINT(20) UNSIGNED NOT NULL,
    `end_pos`     BIGINT(20) UNSIGNED NOT NULL,
    PRIMARY KEY (`server_id`) USING HASH
) ENGINE=NDBCLUSTER   DEFAULT CHARSET=latin1;

该ndb_apply_status表仅在副本上填充，这意味着在源上，该表从不包含任何行；因此，没有必要在那里分配任何 DataMemory东西 ndb_apply_status。

因为这个表是从来自源的数据填充的，所以应该允许复制；任何无意中阻止副本更新 ndb_apply_status或阻止源写入二进制日志的复制过滤或二进制日志过滤规则可能会阻止集群之间的复制正常运行。有关此类过滤规则引起的潜在问题的更多信息，请参阅 复制和二进制日志过滤规则以及 NDB 集群之间的复制。

0此表的epoch列中的 表示源自除 之外的存储引擎的事务NDB。

NDB Cluster Replication 使用该 ndb_binlog_index表来存储二进制日志的索引数据。由于这张表是每个MySQL服务器本地的，不参与集群，所以使用 InnoDB存储引擎。这意味着它必须在 参与源集群的每个mysqld上单独创建。（二进制日志本身包含来自集群中所有 MySQL 服务器的更新。）该表定义如下：

CREATE TABLE `ndb_binlog_index` (
    `Position` BIGINT(20) UNSIGNED NOT NULL,
    `File` VARCHAR(255) NOT NULL,
    `epoch` BIGINT(20) UNSIGNED NOT NULL,
    `inserts` INT(10) UNSIGNED NOT NULL,
    `updates` INT(10) UNSIGNED NOT NULL,
    `deletes` INT(10) UNSIGNED NOT NULL,
    `schemaops` INT(10) UNSIGNED NOT NULL,
    `orig_server_id` INT(10) UNSIGNED NOT NULL,
    `orig_epoch` BIGINT(20) UNSIGNED NOT NULL,
    `gci` INT(10) UNSIGNED NOT NULL,
    `next_position` bigint(20) unsigned NOT NULL,
    `next_file` varchar(255) NOT NULL,
    PRIMARY KEY (`epoch`,`orig_server_id`,`orig_epoch`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

表的大小ndb_binlog_index取决于每个二进制日志文件的纪元数和二进制日志文件的数量。每个二进制日志文件的纪元数通常取决于每个纪元生成的二进制日志量和二进制日志文件的大小，较小的纪元会导致每个文件的纪元数较多。您应该知道 ndb_binlog_index，即使 --ndb-log-empty-epochs选项为 OFF，空时期也会对表产生插入，这意味着每个文件的条目数取决于文件使用的时间长度；这种关系可以用此处显示的公式表示：

[number of epochs per file] = [time spent per file] / TimeBetweenEpochs

繁忙的 NDB Cluster 定期写入二进制日志，并且可能比安静的更快地旋转二进制日志文件。这意味着一个“安静”的NDB Cluster --ndb-log-empty-epochs=ON实际上 ndb_binlog_index每个文件的行数比一个有大量活动的 NDB Cluster 多得多。

当mysqld以 --ndb-log-orig选项启动时， orig_server_id和 orig_epoch列分别存储事件发起的服务器的 ID 和事件在发起服务器上发生的纪元，这在使用多个源的 NDB Cluster 复制设置中很有用. 该SELECT语句用于在多源设置中找到最接近副本上最高应用纪元的二进制日志位置（请参阅 第 18.7.10 节，“NDB 集群复制：双向和循环复制”) 使用这两列，它们没有索引。这可能会在尝试故障转移时导致性能问题，因为查询必须执行表扫描，尤其是当源已使用 --ndb-log-empty-epochs=ON. 您可以通过向这些列添加索引来缩短多源故障转移时间，如下所示：

ALTER TABLE mysql.ndb_binlog_index
    ADD INDEX orig_lookup USING BTREE (orig_server_id, orig_epoch);

当从单个源复制到单个副本时，添加此索引没有任何好处，因为在这种情况下用于获取二进制日志位置的查询不使用 orig_server_idor orig_epoch。

有关使用和 列 的更多信息， 请参阅第 18.7.8 节，“使用 NDB Cluster 复制实现故障转移” 。next_positionnext_file

下图显示了 NDB Cluster 复制源服务器、其二进制日志注入器线程和mysql.ndb_binlog_index表的关系。

图 18.15 复制源集群

该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 复制启用冲突解决，有必要使用有关应解决冲突的一个或多个 SQL 节点的控制信息创建并填充此表。根据要采用的冲突解决类型和方法，这可能是源服务器、副本服务器或两者都是服务器。在一个简单的源副本设置中，数据也可以在副本上本地更改，这通常是副本。在更复杂的复制方案中，例如双向复制，这通常是所有涉及的源。有关更多信息，请参阅 第 18.7.11 节，“NDB Cluster 复制冲突解决”。

该ndb_replication表允许在冲突解决范围之外对二进制日志记录进行表级控制，在这种情况下conflict_fn指定为NULL，而其余列值用于控制与通配符表达式匹配的给定表或一组表的二进制日志记录。通过为该binlog_type列设置适当的值，您可以使给定表或表的日志记录使用所需的二进制日志格式，或者完全禁用二进制日志记录。此列的可能值及其值和说明如下表所示：

几个值等效于mysqld日志记录选项、 和 binlog_type的各种组合，如下表所示： --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可以使用通配符来匹配任何数据库名称、表名称和服务器 ID 的任意组合。如果表中有多个潜在匹配，则选择最佳匹配，根据此处显示的表，其中W表示通配符匹配，E表示完全匹配，并且Quality列中的值越大，匹配越好：

因此，数据库名称、表名称和服务器 ID 的完全匹配被认为是最好的（最强的），而最弱的（最差的）匹配是所有三列的通配符匹配。选择要应用的规则时，只考虑比赛的强度；行在表中出现的顺序对该确定没有影响。

记录完整或部分行。  有两种记录行的基本方法，由 mysqld--ndb-log-updated-only的选项设置决定：

通常只记录更新的列就足够了——而且效率更高；但是，如果您需要记录完整的行，您可以通过设置 --ndb-log-updated-only为 0或来实现OFF。

将更改的数据记录为更新。  MySQL 服务器 --ndb-log-update-as-write 选项的设置决定了是否使用“之前”图像执行日志记录。

因为更新和删除操作的冲突解决是在 MySQL 服务器的更新处理程序中完成的，所以有必要控制复制源执行的日志记录，以便更新是更新而不是写入；也就是说，更新被视为对现有行的更改而不是写入新行，即使这些更新替换了现有行。

该选项默认开启；换句话说，更新被视为写入。也就是说，更新默认情况下作为 write_row事件写入二进制日志中，而不是作为update_row事件。

要禁用该选项，请 使用 或 启动源mysqld。从 NDB 表复制到使用不同存储引擎的表时，您必须这样做；有关详细信息，请参阅 从 NDB 到其他存储引擎的复制和 从 NDB 到非事务性存储引擎的复制。 --ndb-log-update-as-write=0--ndb-log-update-as-write=OFF