16.1.3.6 使用 GTID 复制的限制

由于基于 GTID 的复制依赖于事务，因此在使用它时不支持 MySQL 中其他可用的功能。本节提供有关 GTID 复制限制和限制的信息。

涉及非事务性存储引擎的更新. 当使用 GTID 时，不能在与使用事务性存储引擎(例如InnoDB)进行 table 更新的同一语句或事务中对使用非事务性存储引擎(例如MyISAM)进行 table 更新。

此限制是由于以下事实：在同一事务中对使用非事务性存储引擎的 table 的更新与对使用事务性存储引擎的 table 的更新混合在一起可能导致将多个 GTID 分配给同一事务。

当源和副本对同一 table 的各自版本使用不同的存储引擎时，也会发生此类问题，其中一个存储引擎是事务性的，而另一个则不是事务性的。还应注意，定义为对非事务 table 进行操作的触发器可能是导致这些问题的原因。

在上述任何情况下，事务和 GTID 之间的一对一对应关系都被破坏，结果是基于 GTID 的复制无法正确运行。

CREATE TABLE ... SELECT 语句. 使用基于 GTID 的复制时，不允许创建 table...选择语句。当binlog_format设置为 STATEMENT 时，CREATE TABLE ... SELECT语句作为具有一个 GTID 的一个事务记录在二进制日志中，但是如果使用 ROW 格式，则该语句被记录为具有两个 GTID 的两个事务。如果源使用 STATEMENT 格式，而副本使用 ROW 格式，则副本将无法正确处理事务，因此CREATE TABLE ... SELECT语句不允许使用 GTID，以防止出现这种情况。

临时 table. 使用 GTID 时(即，当enforce_gtid_consistency系统变量设置为ON时)，事务，过程，函数和触发器内部不支持创建临时 table和拖放临时 table语句。可以在启用了 GTID 的情况下使用这些语句，但只能在任何事务之外且仅通过autocommit=1来使用。

防止执行不受支持的语句. 为了防止执行会导致基于 GTID 的复制失败的语句，在启用 GTID 时，必须使用--enforce-gtid-consistency选项启动所有服务器。这会导致本节前面讨论的任何类型的语句失败，并显示错误。

请注意，--enforce-gtid-consistency仅在为语句执行二进制日志记录时才有效。如果在服务器上禁用了二进制日志记录，或者由于过滤器将语句删除而未将语句写入二进制日志，则不会检查或强制执行未记录语句的 GTID 一致性。

有关启用 GTID 时其他必需的启动选项的信息，请参阅第 16.1.3.4 节，“使用 GTID 设置复制”。

跳过 Transaction. 使用 GTID 时不支持sql_slave_skip_counter。如果需要跳过事务，请改用源的gtid_executed变量的值。有关说明，请参见第 16.1.7.3 节“跳过 Transaction”。

忽略服务器. 使用 GTID 时，更改为主语句的 IGNORE_SERVER_IDS 选项已被弃用，因为已应用的事务将被自动忽略。在开始基于 GTID 的复制之前，请检查并清除以前在相关服务器上设置的所有忽略的服务器 ID 列 table。可以为各个通道发出的显示从站状态语句显示存在的服务器 ID 的列 table(如果有的话)。如果没有列 table，则Replicate_Ignore_Server_Ids字段为空白。

GTID 模式和 mysqldump. 如果目标服务器的二进制日志中没有 GTID，则可以将使用mysqldump进行的转储导入到启用了 GTID 模式的 MySQL 服务器中。

GTID 模式和 mysql_upgrade. 当服务器在启用全局事务标识符(GTID)的情况下(gtid_mode=ON)运行时，请勿通过mysql_upgrade(--write-binlog选项)启用二进制日志记录。