ndb_apply_status 用于记录已从源端复制到副本的操作。如果副本上不存在 ndb_apply_status 表，ndb_restore 会重新创建它。ndb_apply_status is used to keep a record of the operations that have been replicated from the source to the replica. If the ndb_apply_status table does not exist on the replica, ndb_restore re-creates it.

与 ndb_binlog_index 的情况不同，此表中的数据并不针对 (副本) 集群中的任何单个 SQL 节点，因此 ndb_apply_status 可以使用 NDBCLUSTER 存储引擎，如下所示：Unlike the case with ndb_binlog_index, the data in this table is not specific to any one SQL node in the (replica) cluster, and so ndb_apply_status can use the NDBCLUSTER storage engine, as shown here:

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=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

ndb_apply_status 表仅在副本上填充，这意味着在源端，该表永远不包含任何行；因此，在那里无需为 ndb_apply_status 分配任何 DataMemory。The ndb_apply_status table is populated only on replicas, which means that, on the source, this table never contains any rows; thus, there is no need to allot any DataMemory to ndb_apply_status there.

由于此表的数据来自源，因此它应该被允许进行复制；任何不小心阻止副本更新 ndb_apply_status 的复制过滤或二进制日志过滤规则，或者阻止源写入二进制日志的规则，都可能导致集群之间的复制无法正常运行。有关此类过滤规则可能引起的问题的更多信息，请参阅 NDB 集群之间复制及二进制日志过滤规则。Because this table is populated from data originating on the source, it should be allowed to replicate; any replication filtering or binary log filtering rules that inadvertently prevent the replica from updating ndb_apply_status, or that prevent the source from writing into the binary log may prevent replication between clusters from operating properly. For more information about potential problems arising from such filtering rules, see Replication and binary log filtering rules with replication between NDB Clusters.

可以删除此表，但不推荐这样做。删除它会使所有 SQL 节点进入只读模式；NDB 会检测到此表已被删除，并重新创建它，此后又可以执行更新操作。删除并重新创建 ndb_apply_status 会在二进制日志中产生一个间隙事件；该间隙事件会导致副本 SQL 节点停止从源应用更改，直到重新启动复制通道。It is possible to delete this table, but this is not recommended. Deleting it puts all SQL nodes in read-only mode; NDB detects that this table has been dropped, and re-creates it, after which it is possible once again to perform updates. Dropping and re-creating ndb_apply_status creates a gap event in the binary log; the gap event causes replica SQL nodes to stop applying changes from the source until the replication channel is restarted.

此表中 epoch 列的 0 表示事务来源于 NDB 以外的存储引擎。0 in the epoch column of this table indicates a transaction originating from a storage engine other than NDB.

ndb_apply_status 用于记录从上游源复制到副本集群的事务已经被应用到哪个时间点。此信息会在 NDB 在线备份中捕获，但（按设计）不会被 ndb_restore 恢复。在某些情况下，将这些信息恢复以用于新的设置可能会很有帮助；您可以通过使用 ndb_restore 并加上 --with-apply-status 选项来实现。有关更多信息，请参见该选项的描述。ndb_apply_status is used to record which epoch transactions have been replicated and applied to a replica cluster from an upstream source. This information is captured in an NDB online backup, but (by design) it is not restored by ndb_restore. In some cases, it can be helpful to restore this information for use in new setups; you can do this by invoking ndb_restore with the --with-apply-status option. See the description of the option for more information.

NDB 集群复制使用 ndb_binlog_index 表来存储二进制日志的索引数据。由于该表是每个 MySQL 服务器本地的，并不参与集群，因此它使用 InnoDB 存储引擎。这意味着它必须在每个参与源集群的 mysqld 上单独创建。（二进制日志本身包含来自集群中所有 MySQL 服务器的更新。）该表定义如下：NDB Cluster Replication uses the ndb_binlog_index table for storing the binary log's indexing data. Since this table is local to each MySQL server and does not participate in clustering, it uses the InnoDB storage engine. This means that it must be created separately on each mysqld participating in the source cluster. (The binary log itself contains updates from all MySQL servers in the cluster.) This table is defined as follows:

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=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

ndb_binlog_index 表的大小取决于每个二进制日志文件的时期数以及二进制日志文件的数量。每个二进制日志文件的时期数通常取决于每个时期生成的二进制日志量以及二进制日志文件的大小，时期越小，每个文件的时期数越多。你应该注意，即使 --ndb-log-empty-epochs 选项为 OFF，空时期仍会向 ndb_binlog_index 表插入数据，这意味着每个文件的条目数取决于文件使用的时间长度；这种关系可以通过下面显示的公式表示：The size of the ndb_binlog_index table is dependent on the number of epochs per binary log file and the number of binary log files. The number of epochs per binary log file normally depends on the amount of binary log generated per epoch and the size of the binary log file, with smaller epochs resulting in more epochs per file. You should be aware that empty epochs produce inserts to the ndb_binlog_index table, even when the --ndb-log-empty-epochs option is OFF, meaning that the number of entries per file depends on the length of time that the file is in use; this relationship can be represented by the formula shown here:

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

A busy NDB Cluster writes to the binary log regularly and presumably rotates binary log files more quickly than a quiet one. This means that a “quiet” NDB Cluster with --ndb-log-empty-epochs=ON can actually have a much higher number of ndb_binlog_index rows per file than one with a great deal of activity.

当mysqld 使用--ndb-log-orig 选项启动时，orig_server_id 和 orig_epoch 列分别存储事件发生的源服务器 ID 以及事件在源服务器上发生的纪元，这在使用多个源的 NDB Cluster 复制设置中非常有用。在多源设置中用于查找副本上最高已应用纪元的最接近二进制日志位置的SELECT 语句（参见第 25.7.10 节，“NDB Cluster 复制：双向和循环复制”）使用了这两列，而它们没有索引。这可能会导致在尝试故障转移时出现性能问题，因为查询必须执行表扫描，尤其是在源服务器已使用--ndb-log-empty-epochs=ON 运行时。您可以通过为这些列添加索引来改善多源故障转移时间，如下所示：When mysqld is started with the --ndb-log-orig option, the orig_server_id and orig_epoch columns store, respectively, the ID of the server on which the event originated and the epoch in which the event took place on the originating server, which is useful in NDB Cluster replication setups employing multiple sources. The SELECT statement used to find the closest binary log position to the highest applied epoch on the replica in a multi-source setup (see Section 25.7.10, “NDB Cluster Replication: Bidirectional and Circular Replication”) employs these two columns, which are not indexed. This can lead to performance issues when trying to fail over, since the query must perform a table scan, especially when the source has been running with --ndb-log-empty-epochs=ON. You can improve multi-source failover times by adding an index to these columns, as shown here:

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

在从单个源复制到单个副本时，添加此索引没有任何好处，因为在这种情况下用于获取二进制日志位置的查询不会使用 orig_server_id 或 orig_epoch。Adding this index provides no benefit when replicating from a single source to a single replica, since the query used to get the binary log position in such cases makes no use of orig_server_id or orig_epoch.

有关使用 next_position 和 next_file 列的更多信息，请参见 第 25.7.8 节，“使用 NDB Cluster 复制实现故障切换”。See Section 25.7.8, “Implementing Failover with NDB Cluster Replication”, for more information about using the next_position and next_file columns.

下图显示了 NDB Cluster 复制源服务器、其二进制日志注入线程和 mysql.ndb_binlog_index 表的关系。The following figure shows the relationship of the NDB Cluster replication source server, its binary log injector thread, and the mysql.ndb_binlog_index table.

图 25.13 复制源集群Figure 25.13 The Replication Source Cluster

ndb_replication 表用于控制二进制日志记录和冲突解决，并且按表为单位进行操作。该表中的每一行对应一个正在复制的表，决定如何记录该表的更改，并且如果指定了冲突解决函数，还决定如何解决该表的冲突。The ndb_replication table is used to control binary logging and conflict resolution, and acts on a per-table basis. Each row in this table corresponds to a table being replicated, determines how to log changes to the table and, if a conflict resolution function is specified, and determines how to resolve conflicts for that table.

与 ndb_apply_status 和 ndb_replication 表不同，ndb_replication 表必须手动创建，使用此处显示的 SQL 语句：Unlike the ndb_apply_status and ndb_replication tables, the ndb_replication table must be created manually, using the SQL statement shown here:

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);

此表的列如下，并附有描述：The columns of this table are listed here, with descriptions:

要启用 NDB 复制的冲突解决，必须在 SQL 节点上创建并填写此表，以提供冲突应解决的控制信息。根据所使用的冲突解决类型和方法，这可能是在源服务器、副本服务器或两个服务器上。在数据也可以在副本本地更改的简单源-副本设置中，这通常是副本服务器。在更复杂的复制方案中，例如双向复制，这通常涉及所有源服务器。有关更多信息，请参见 第 25.7.12 节，“NDB 集群复制冲突解决”。To enable conflict resolution with NDB Replication, it is necessary to create and populate this table with control information on the SQL node or nodes on which the conflict should be resolved. Depending on the conflict resolution type and method to be employed, this may be the source, the replica, or both servers. In a simple source-replica setup where data can also be changed locally on the replica this is typically the replica. In a more complex replication scheme, such as bidirectional replication, this is usually all of the sources involved. See Section 25.7.12, “NDB Cluster Replication Conflict Resolution”, for more information.

ndb_replication 表允许在冲突解决范围之外对二进制日志进行表级控制，在这种情况下，conflict_fn 被指定为 NULL，而其余列值用于控制给定表或与通配符表达式匹配的一组表的二进制日志。通过为 binlog_type 列设置适当的值，可以使给定表或表组的日志使用所需的二进制日志格式，或完全禁用二进制日志。此列的可能值及其描述如下表所示：The ndb_replication table allows table-level control over binary logging outside the scope of conflict resolution, in which case conflict_fn is specified as NULL, while the remaining column values are used to control binary logging for a given table or set of tables matching a wildcard expression. By setting the proper value for the binlog_type column, you can make logging for a given table or tables use a desired binary log format, or disabling binary logging altogether. Possible values for this column, with values and descriptions, are shown in the following table:

多个 binlog_type 值相当于各种 mysqld 日志选项 --ndb-log-updated-only、--ndb-log-update-as-write 和 --ndb-log-update-minimal 的组合，如下表所示：Several binlog_type values are equivalent to various combinations of the mysqld logging options --ndb-log-updated-only, --ndb-log-update-as-write, and --ndb-log-update-minimal, as shown in the following table:

通过使用适当的 db、table_name 和 binlog_type 列值向 ndb_replication 表插入行，可以为不同的表设置不同格式的二进制日志。设置二进制日志格式时，应使用前表中显示的内部整数值。以下两个语句将二进制日志设置为对表 test.a 记录完整行（值 3），对表 test.b 仅记录更新（值 2）：Binary logging can be set to different formats for different tables by inserting rows into the ndb_replication table using the appropriate db, table_name, and binlog_type column values. The internal integer value shown in the preceding table should be used when setting the binary logging format. The following two statements set binary logging to logging of full rows ( value 3) for table test.a, and to logging of updates only ( value 2) for table 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);

要禁用一个或多个表的日志记录，请将 binlog_type 设置为 1，如下所示：To disable logging for one or more tables, use 1 for binlog_type, as shown here:

# 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 节点没有对给定表执行二进制日志记录，它将不会接收到这些表的行更改事件。这意味着它并不是接收了所有更改然后丢弃一些，而是它根本没有订阅这些更改。Disabling logging for a given table is the equivalent of setting sql_log_bin = 0, except that it applies to one or more tables individually. If an SQL node is not performing binary logging for a given table, it is not sent the row change events for those tables. This means that it is not receiving all changes and discarding some, but rather it is not subscribing to these changes.

禁用日志记录在许多情况下都很有用，包括以下列出的原因：Disabling logging can be useful for a number of reasons, including those listed here:

使用通配符进行匹配。 为了避免在复制设置中为每一个数据库、表和 SQL 节点的组合在 ndb_replication 表中插入一行，NDB 支持在此表的 db、table_name 和 server_id 列上使用通配符匹配。分别用于 db 和 table_name 的数据库和表名可以包含以下通配符之一或两者：Matching with wildcards.  In order not to make it necessary to insert a row in the ndb_replication table for each and every combination of database, table, and SQL node in your replication setup, NDB supports wildcard matching on the this table's db, table_name, and server_id columns. Database and table names used in, respectively, db and table_name may contain either or both of the following wildcards:

（这些与 MySQL LIKE 运算符支持的通配符相同。）(These are the same wildcards as supported by the MySQL LIKE operator.)

server_id 列支持 0 作为类似于 _（匹配任何内容）的通配符。这在前面显示的示例中有使用。The server_id column supports 0 as a wildcard equivalent to _ (matches anything). This is used in the examples shown previously.

ndb_replication 表中的某行可以使用通配符以任何组合匹配数据库名、表名和服务器 ID。当表中存在多个潜在匹配项时，将根据此处显示的表选择最佳匹配，其中 W 表示通配符匹配，E 表示完全匹配，Quality 列的值越大，匹配越好：A given row in the ndb_replication table can use wildcards to match any of the database name, table name, and server ID in any combination. Where there are multiple potential matches in the table, the best match is chosen, according to the table shown here, where W represents a wildcard match, E an exact match, and the greater the value in the Quality column, the better the match:

因此，数据库名称、表名称和服务器 ID 的精确匹配被认为是最佳（最强）的匹配，而最弱（最差）的匹配是在所有三列上使用通配符匹配。在选择应用哪条规则时，仅考虑匹配的强度；表中行的顺序不会影响此判断。Thus, an exact match on database name, table name, and server ID is considered best (strongest), while the weakest (worst) match is a wildcard match on all three columns. Only the strength of the match is considered when choosing which rule to apply; the order in which the rows occur in the table has no effect on this determination.

记录完整或部分行。 记录行有两种基本方法，这取决于 --ndb-log-updated-only 选项在 mysqld 中的设置：Logging Full or Partial Rows.  There are two basic methods of logging rows, as determined by the setting of the --ndb-log-updated-only option for mysqld:

通常只记录更新的列就足够了——而且效率更高；但是，如果你需要记录整行，可以通过将 --ndb-log-updated-only 设置为 0 或 OFF 来实现。It is usually sufficient—and more efficient—to log updated columns only; however, if you need to log full rows, you can do so by setting --ndb-log-updated-only to 0 or OFF.

将更改的数据记录为更新。 MySQL 服务器的 --ndb-log-update-as-write 选项的设置决定了日志记录是带有还是不带有 “before” 图像。Logging Changed Data as Updates.  The setting of the MySQL Server's --ndb-log-update-as-write option determines whether logging is performed with or without the “before” image.

由于更新和删除操作的冲突解决是在 MySQL 服务器的更新处理器中完成的，因此有必要控制复制源执行的日志记录，使更新被视为更新而不是写入；也就是说，使更新被视为现有行的更改而不是新行的写入，即使这些操作会替换现有行。Because conflict resolution for updates and delete operations is done in the MySQL Server's update handler, it is necessary to control the logging performed by the replication source such that updates are updates and not writes; that is, such that updates are treated as changes in existing rows rather than the writing of new rows, even though these replace existing rows.

此选项默认开启；换句话说，更新被视为写入。也就是说，默认情况下，更新会在二进制日志中作为write_row事件写入，而不是作为update_row事件。This option is turned on by default; in other words, updates are treated as writes. That is, updates are by default written as write_row events in the binary log, rather than as update_row events.

要禁用该选项，请使用 --ndb-log-update-as-write=0 或 --ndb-log-update-as-write=OFF 启动源 mysqld。当从 NDB 表复制到使用不同存储引擎的表时，必须执行此操作；有关详细信息，请参见 从 NDB 到其他存储引擎的复制 和 从 NDB 到非事务性存储引擎的复制。To disable the option, start the source mysqld with --ndb-log-update-as-write=0 or --ndb-log-update-as-write=OFF. You must do this when replicating from NDB tables to tables using a different storage engine; see Replication from NDB to other storage engines, and Replication from NDB to a nontransactional storage engine, for more information.