必须在源和副本上为解决冲突做准备。以下列表描述了这些任务：

在使用函数NDB$OLD()、 NDB$MAX()和 NDB$MAX_DELETE_WIN()进行基于时间戳的冲突解决时，我们通常将用于确定更新的列称为“时间戳”列。但是，该列的数据类型是 never TIMESTAMP；相反，它的数据类型应该是INT ( INTEGER) 或 BIGINT. “ 时间戳”列 也应该是 UNSIGNED和。NOT NULL

本节后面讨论的NDB$EPOCH()和 NDB$EPOCH_TRANS()函数通过比较应用在主 NDB Cluster 和辅助 NDB Cluster 上的复制时期的相对顺序来工作，并且不使用时间戳。

我们可以根据“之前” 和“之后”图像来查看更新操作，即应用更新之前和之后的表状态。通常，当更新一个带有主键的表时，“之前” 的图像并不是很重要；然而，当我们需要在每次更新的基础上确定是否在副本上使用更新的值时，我们需要确保两个图像都写入源的二进制日志。这是通过 mysqld--ndb-log-update-as-write的选项完成的，如本节后面所述。

通常在可能发生冲突的服务器上启用冲突解决。与记录方法选择一样，它由表中的条目启用 mysql.ndb_replication。

NBT_UPDATED_ONLY_MINIMALand NBT_UPDATED_FULL_MINIMAL可以与 NDB$EPOCH(), NDB$EPOCH2(), 和一起使用NDB$EPOCH_TRANS()，因为它们不需要不是主键的列的“之前”值。需要旧值（例如NDB$MAX()和 NDB$OLD()）的冲突解决算法无法正确处理这些 binlog_type值。

本节提供有关可用于 NDB 复制冲突检测和解决的功能的详细信息。这些函数按字母顺序列于此处：

新开发银行$OLD()

如果column_name源和副本上的值相同，则应用更新；否则，更新不会应用于副本，并且会向日志中写入异常。以下伪代码说明了这一点：

if (source_old_column_value == replica_current_column_value)
  apply_update();
else
  log_exception();

该函数可用于“同值取胜”的 冲突解决。这种类型的冲突解决可确保不会将更新应用到来自错误来源的副本。

新开发银行$MAX()

如果来自源的给定行的“时间戳”列值高于副本上的值，则应用它；否则它不会应用于副本。以下伪代码说明了这一点：

if (source_new_column_value > replica_current_column_value)
  apply_update();

此函数可用于“最大时间戳获胜”冲突解决。这种类型的冲突解决可确保在发生冲突时，最近更新的行的版本是持续存在的版本。

NDB$MAX_DELETE_WIN()

这是NDB$MAX(). 由于没有可用于删除操作的时间戳，删除使用NDB$MAX()实际上被处理为NDB$OLD，但对于某些用例，这不是最佳选择。对于NDB$MAX_DELETE_WIN()，如果添加或更新来自源的现有行的给定行的 “时间戳”列值高于副本上的值，则应用它。但是，删除操作被视为始终具有较高的值。以下伪代码说明了这一点：

if ( (source_new_column_value > replica_current_column_value)
        ||
      operation.type == "delete")
  apply_update();

该函数可用于“最大时间戳，删除胜出”冲突解决。这种类型的冲突解决确保在发生冲突时，被删除或（否则）最近更新的行的版本是持续存在的版本。

NDB$EPOCH()

该NDB$EPOCH()函数跟踪复制时期在副本集群上应用的顺序，相对于在副本上发起的更改。此相对顺序用于确定源自副本的更改是否与源自本地的任何更改并发，并因此可能发生冲突。

的描述中的大部分内容 NDB$EPOCH()也适用于 NDB$EPOCH_TRANS(). 任何例外情况都会在文中注明。

NDB$EPOCH()是不对称的，在双向复制配置（有时称为“主动-主动” 复制）中的一个 NDB Cluster 上运行。我们在这里将其运行的集群称为主要集群，将另一个集群称为次要集群。primary 上的副本负责检测和处理冲突，而 secondary 上的副本不参与任何冲突检测或处理。

当主节点上的副本检测到冲突时，它会将事件注入到自己的二进制日志中以补偿这些冲突；这确保了辅助 NDB Cluster 最终会与主集群重新对齐，从而防止主集群和辅助集群发生分歧。这种补偿和重新调整机制要求主 NDB Cluster 始终赢得与次级的任何冲突 - 也就是说，在发生冲突时始终使用主的更改而不是次要的更改。这个“主要总是获胜” 的规则具有以下含义：

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 $ OLD()）。在创建要使用它的数据表之前，您必须创建任何异常表。 NDB$EPOCH_TRANS()

与本节中讨论的其他冲突检测功能一样NDB$EPOCH()， NDB$EPOCH_TRANS()通过在表中包含相关条目来激活mysql.ndb_replication （请参阅ndb_replication 表）。在这种情况下，主要和次要 NDB Clusters 的角色完全由 mysql.ndb_replicationtable 条目确定。

由于 和 使用的冲突检测算法 NDB$EPOCH()是 不对称的，因此您必须 对主副本和辅助副本 NDB$EPOCH_TRANS()的条目使用不同的值。server_id

仅操作之间的冲突DELETE不足以触发使用 NDB$EPOCH()or 的冲突NDB$EPOCH_TRANS()，并且历元内的相对位置无关紧要。

NDB$EPOCH() 的限制

NDB$EPOCH()用于执行冲突检测 时，当前适用以下限制 ：

NDB$EPOCH_TRANS()

NDB$EPOCH_TRANS()扩展 NDB$EPOCH()功能。使用“ primary wins all ”规则（请参阅 NDB$EPOCH() ）以相同的方式检测和处理冲突，但有一个额外的条件，即在发生冲突的同一事务中更新的任何其他行也被视为在冲突。换句话说，where NDB$EPOCH()重新对齐次级上的各个冲突行，NDB$EPOCH_TRANS() 重新对齐冲突的事务。

此外，任何可检测到依赖于冲突事务的事务也被视为冲突，这些依赖性由辅助集群的二进制日志的内容确定。由于二进制日志仅包含数据修改操作（插入、更新和删除），因此仅使用重叠的数据修改来确定事务之间的依赖关系。

NDB$EPOCH_TRANS()受与 相同的条件和限制NDB$EPOCH()，此外还要求使用版本 2 二进制日志行事件（log_bin_use_v1_row_events 等于 0），这会在二进制日志中为每个事件增加 2 个字节的存储开销。此外，所有事务 ID 都必须记录在辅助节点的二进制日志（--ndb-log-transaction-id 选项）中，这进一步增加了可变开销（每行最多 13 个字节）。

参见NDB$EPOCH()。

NDB$EPOCH2()

在 NDB 7.4 中添加的NDB$EPOCH2()功能类似于NDB$EPOCH()，除了它 NDB$EPOCH2()提供了双向复制拓扑的删除-删除处理。ndb_slave_conflict_role在这种情况下，通过将系统变量设置为每个源上的适当值（通常 , 各一个PRIMARY） ，将主要角色和次要角色分配给两个源 SECONDARY。完成此操作后，次级所做的修改将由初级反映回次级，然后有条件地应用它们。

NDB$EPOCH2_TRANS()

NDB 7.4 新增，NDB$EPOCH2_TRANS()扩展NDB$EPOCH2()功能。以相同的方式检测和处理冲突，并将主要和次要角色分配给复制集群，但额外的条件是在发生冲突的同一事务中更新的任何其他行也被视为冲突。也就是说，NDB$EPOCH2()重新对齐辅助节点上的各个冲突行，同时 NDB$EPOCH_TRANS()重新对齐冲突的事务。

在哪里NDB$EPOCH()和 NDB$EPOCH_TRANS()使用每行指定的元数据，每个最后修改的时期，来确定在主节点上来自辅助节点的传入复制行更改是否与本地提交的更改并发；并发更改被认为是冲突的，随后的例外是表更新和次要的重新对齐。当在主数据库上删除一行时会出现问题，因此不再有任何最后修改的纪元可用于确定是否有任何复制操作冲突，这意味着不会检测到冲突的删除操作。这可能会导致分歧，例如一个集群上的删除与另一个集群上的删除和插入并发； NDB$EPOCH()和 NDB$EPOCH_TRANS()。

NDB$EPOCH2()通过忽略任何删除-删除冲突，并避免任何潜在的结果分歧，绕过了刚刚描述的问题——在 PRIMARY 上存储有关已删除行的信息。这是通过将任何成功应用于辅助节点并从辅助节点复制的操作反映回辅助节点来实现的。在它返回到辅助节点时，它可用于在辅助节点上重新应用操作，该操作已被源自主节点的操作删除。

使用 时NDB$EPOCH2()，您应该记住，辅助应用从主应用删除，删除新行，直到它被反射操作恢复。理论上，后续在 secondary 上的 insert 或 update 会与 primary 上的 delete 发生冲突，但在这种情况下，我们选择忽略这一点，让 secondary “获胜”，为了防止集群之间的分歧。换句话说，删除后，primary 不会检测到冲突，而是立即采用 secondary 的后续更改。正因为如此，次要状态在进入最终（稳定）状态时可以重新访问多个先前提交的状态，并且其中一些可能是可见的。

您还应该知道，将所有操作从辅助设备反映回主设备会增加主设备的日志二进制日志的大小，以及对带宽、CPU 使用率和磁盘 I/O 的需求。

次要应用反射操作取决于次要目标行的状态。Ndb_conflict_reflected_op_prepare_count 可以通过检查 NDB 7.4.2 中添加的和 Ndb_conflict_reflected_op_discard_count 状态变量来跟踪是否在次级上应用了反映的更改 。应用的更改次数就是这两个值之间的差值（注意Ndb_conflict_reflected_op_prepare_count 始终大于或等于 Ndb_conflict_reflected_op_discard_count）。

当且仅当以下两个条件都为真时，才会应用事件：

如果这两个条件都不满足，则反射操作将被次级丢弃。

要使用NDB$OLD()冲突解决功能，还需要为每个要使用这种冲突解决的表创建一个例外表NDB。使用NDB$EPOCH()or 时也是如此NDB$EPOCH_TRANS()。该表的名称是要对其应用冲突解决的表的名称，并$EX附加了字符串。（例如，如果原始表 mytable的名称为 ，则相应的异常表名称应为mytable$EX。）在 NDB 7.4.1 之前，创建异常表的语法如下所示：

CREATE TABLE original_table$EX  (
    server_id INT UNSIGNED,
    source_server_id INT UNSIGNED,
    source_epoch BIGINT UNSIGNED,
    count INT UNSIGNED,

    original_table_pk_columns,

    [additional_columns,]

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

NDB 7.4.1 及更高版本支持扩展的异常表定义，其中包括提供有关异常类型、原因和原始交易信息的可选列。在这些版本中，创建异常表的语法如下所示：

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 7.4.1 开始，如果异常表使用一个或多个可选列NDB$OP_TYPE， NDB$CFT_CAUSE或 NDB$ORIG_TRANSID在本节后面讨论，则每个必需的列也必须使用前缀命名NDB$。如果需要，您可以使用NDB$前缀来命名所需的列，即使您没有定义任何可选列，但在这种情况下，所有四个必需的列都必须使用前缀来命名。

在这些列之后，构成原始表主键的列应按照它们用于定义原始表主键的顺序进行复制。与原始表的主键列重复的列的数据类型应与原始列的数据类型相同（或大于）。在 NDB Cluster 7.3 及更早版本中，异常表的主键必须逐列复制。从 NDB 7.4.1 开始，可以改用主键列的子集。

无论使用的 NDB Cluster 版本如何，异常表都必须使用NDB存储引擎。NDB$OLD()（与例外表一起 使用的示例将在本节后面显示。）

可以选择在复制的主键列之后定义其他列，但不能在它们之前；任何此类额外的列都不能NOT NULL。在 NDB 7.4.1 及更高版本中，支持三个额外的、预定义的可选列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_ROWREFRESH_ROWREAD_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列（如果使用）包含原始交易的 ID。此列应定义如下：

NDB$ORIG_TRANSID BIGINT UNSIGNED NOT NULL

NDB$ORIG_TRANSID是由 生成的 64 位值NDB。该值可用于关联属于来自相同或不同异常表的相同冲突事务的多个异常表条目。

在 NDB 7.4.1 及更高版本中，不属于原始表主键的其他引用列可以命名为 colname$OLDor 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 7.4.2 中添加，分别显示和 Ndb_conflict_fn_epoch2_trans发现的冲突行数。实际重新对齐的行数，包括那些由于与其他冲突行属于同一事务或依赖于相同事务而受到影响的行数，由 给出 。 NDB$EPOCH2()NDB$EPOCH2_TRANS()Ndb_conflict_trans_row_reject_count

另一个服务器状态变量 提供了 自上次 启动mysqld以来由于“最大时间戳获胜”Ndb_conflict_fn_max冲突解决而未在当前 SQL 节点上应用行的次数的计数。 提供已应用 基于结果的冲突解决方案的次数计数。Ndb_conflict_fn_max_del_winNDB$MAX_DELETE_WIN()

自上次重新启动给 定mysqld以来，由于“相同时间戳获胜”冲突解决 而未应用行的次数 由全局状态变量给出。除了递增之外 ，未使用的行的主键被插入到 异常表中，如本节其他地方所述。 Ndb_conflict_fn_oldNdb_conflict_fn_old

另见第 18.4.3.8.3 节，“NDB Cluster 状态变量”。

以下示例假设您已经有一个工作的 NDB Cluster 复制设置，如 第 18.7.5 节，“为复制准备 NDB Cluster”和 第 18.7.6 节，“启动 NDB Cluster 复制（单个复制通道）”中所述。

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 7.4.1 及更高版本支持读取操作的跟踪，这使得在循环复制设置中可以管理一个集群中给定行的读取与另一个集群中同一行的更新或删除之间的冲突。此示例使用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上，我们创建一个新部门，然后使用以下 SQL 语句将员工编号 999 移动到该部门：

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) 和更新操作之间。从 NDB 7.4.1 开始，您可以通过 在副本集群上执行来规避此问题。以这种方式获取独占读锁会导致在源上读取的任何行都被标记为需要在副本集群上解决冲突。如果我们在记录这些事务之前以这种方式启用独占读取，那么集群 B上的读取将被跟踪并发送到集群 A进行解析；随后检测到员工行上的冲突，并且集群上的事务SET ndb_log_exclusive_reads = 1B被中止。

冲突在异常表（在集群 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 的单个实例中执行排他行锁定的方式。