binlog_gtid_simple_recovery

此变量控制 MySQL 启动或重新启动时在搜索 GTID 期间如何遍历二进制日志文件。

当 binlog_gtid_simple_recovery=TRUE （默认值）时，gtid_executed 和 gtid_purged 的值是在启动时根据最新和最旧二进制日志文件中的 Previous_gtids_log_event 值计算的。有关计算的描述，请参见 gtid_purged 系统变量。此设置在服务器重新启动期间仅访问两个二进制日志文件。如果服务器上的所有二进制日志都是使用 MySQL 5.7.8 或更高版本生成的，则始终可以安全地使用 binlog_gtid_simple_recovery=TRUE。

如果服务器上存在任何来自 MySQL 5.7.7 或更早版本的二进制日志（例如，在将旧服务器升级到 MySQL 8.4 后），则使用 binlog_gtid_simple_recovery=TRUE，gtid_executed 和 gtid_purged 可能在以下两种情况下初始化不正确

如果在这两种情况下都计算出了不正确的 GTID 集，即使服务器后来重新启动时使用的是 binlog_gtid_simple_recovery=FALSE，它仍然不正确。如果服务器上存在或可能存在这两种情况，请在启动或重新启动服务器之前设置 binlog_gtid_simple_recovery=FALSE。

当设置了 binlog_gtid_simple_recovery=FALSE 时，计算 gtid_executed 和 gtid_purged 的方法，如 The gtid_purged System Variable 中所述，会更改为按以下方式迭代二进制日志文件。

enforce_gtid_consistency

根据此变量的值，服务器通过仅允许执行可以使用 GTID 安全地记录的语句来强制执行 GTID 一致性。您 必须 将此变量设置为 ON，然后才能启用基于 GTID 的复制。

可以配置 enforce_gtid_consistency 的值为

--enforce-gtid-consistency 仅在对语句进行二进制日志记录时才会生效。如果在服务器上禁用了二进制日志记录，或者语句没有写入二进制日志（因为它们被过滤器删除），则不会针对没有记录的语句检查或强制执行 GTID 一致性。

当 enforce_gtid_consistency 设置为 ON 时，只有可以使用 GTID 安全语句记录的语句才能被记录，因此此处列出的操作不能与此选项一起使用。

有关更多信息，请参见 Section 19.1.3.7, “Restrictions on Replication with GTIDs”.

在 MySQL 5.7 之前以及该版本系列的早期版本中，布尔型 enforce_gtid_consistency 默认设置为 OFF。为了与这些早期版本保持兼容，枚举默认设置为 OFF，并且设置 --enforce-gtid-consistency 而不带值被解释为将值设置为 ON。该变量还有多个值的文本别名：0=OFF=FALSE、1=ON=TRUE、2=WARN。这与其他枚举类型不同，但保持与先前版本中使用的布尔类型的兼容性。这些更改会影响变量的返回值。使用 SELECT @@ENFORCE_GTID_CONSISTENCY、SHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY' 和 SELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY'，都会返回文本形式，而不是数字形式。这是一个不兼容的更改，因为 @@ENFORCE_GTID_CONSISTENCY 返回布尔值的数字形式，但返回 SHOW 和信息模式的文本形式。

gtid_executed

与全局作用域一起使用时，此变量包含在服务器上执行的所有事务的集合以及已通过 SET gtid_purged 语句设置的 GTID 的表示形式。这与 SHOW BINARY LOG STATUS 和 SHOW REPLICA STATUS 输出中的 Executed_Gtid_Set 列的值相同。此变量的值是一个 GTID 集，有关更多信息，请参见 GTID Sets。

服务器启动时，会初始化 @@GLOBAL.gtid_executed。有关如何迭代二进制日志以填充 gtid_executed 的更多信息，请参见 binlog_gtid_simple_recovery。然后，在执行事务时或执行任何 SET gtid_purged 语句时，GTID 会被添加到该集中。

在任何给定时间，可以在二进制日志中找到的事务集等于 GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged)；也就是说，等于二进制日志中尚未被清除的所有事务。

发出 RESET BINARY LOGS AND GTIDS 会导致此变量重置为空字符串。除因 RESET BINARY LOGS AND GTIDS 而清除集合之外，GTID 不会以其他方式从该集合中删除。

gtid_executed_compression_period

每处理完这么多事务，压缩一次 mysql.gtid_executed 表。当在服务器上启用二进制日志记录时，不会使用此压缩方法，而是会在每次二进制日志轮换时压缩 mysql.gtid_executed 表。当在服务器上禁用二进制日志记录时，压缩线程会休眠，直到执行了指定数量的事务，然后唤醒以执行 mysql.gtid_executed 表的压缩。将此系统变量的值设置为 0 表示该线程永远不会唤醒，因此不会使用此显式压缩方法。相反，压缩会根据需要隐式执行。

InnoDB 事务通过与非 InnoDB 事务不同的单独进程写入 mysql.gtid_executed 表。如果服务器同时包含 InnoDB 事务和非 InnoDB 事务，则此系统变量控制的压缩会干扰此进程的工作，并可能导致其速度显著下降。因此，从该版本开始，建议您将 gtid_executed_compression_period 设置为 0。

所有事务（无论存储引擎如何）都通过相同的进程写入 mysql.gtid_executed 表，并且 gtid_executed_compression_period 的默认值为 0。

有关更多信息，请参见 mysql.gtid_executed Table Compression。

gtid_mode

控制是否启用基于 GTID 的日志记录以及日志可以包含哪种类型的事务。您必须具有足够的权限才能设置全局系统变量。请参见 Section 7.1.9.1, “System Variable Privileges”。在您设置 gtid_mode=ON 之前，必须将 enforce_gtid_consistency 设置为 ON。在修改此变量之前，请参见 Section 19.1.4, “Changing GTID Mode on Online Servers”.

记录的事务可以是匿名的，也可以使用 GTID。匿名事务依靠二进制日志文件和位置来识别特定事务。GTID 事务具有唯一的标识符，用于引用事务。不同的模式如下

从一个值更改为另一个值只能一步一步地进行。例如，如果 gtid_mode 当前设置为 OFF_PERMISSIVE，则可以更改为 OFF 或 ON_PERMISSIVE，但不能更改为 ON。

gtid_purged 和 gtid_executed 的值是持久性的，无论 gtid_mode 的值如何。因此，即使在更改 gtid_mode 的值之后，这些变量也包含正确的值。

gtid_next

此变量用于指定是否以及如何获取下一个 GTID（请参见 Section 19.1.3, “Replication with Global Transaction Identifiers”）。

设置此系统变量的会话值是一个受限操作。会话用户必须具有 REPLICATION_APPLIER 权限（参见 第 19.3.3 节，“复制权限检查”），或设置受限会话变量的足够权限（参见 第 7.1.9.1 节，“系统变量权限”）。

gtid_next 可以取以下任一值：

哪些选项有效取决于 gtid_mode 的设置；有关更多信息，请参见 第 19.1.4.1 节，“复制模式概念”。如果 gtid_mode 为 OFF，设置此变量无效。

将此变量设置为 UUID:NUMBER 或 UUID:TAG:NUMBER 后，并在事务提交或回滚后，必须在执行任何其他语句之前再次显式发出 SET gtid_next 语句。

DROP TABLE 或 DROP TEMPORARY TABLE 在对非临时表和临时表，或对使用事务型存储引擎的临时表和使用非事务型存储引擎的临时表的组合使用时，会以显式错误失败。

有关更多信息，请参见 全局变量 gtid_next，以及 第 19.1.4 节，“在在线服务器上更改 GTID 模式”。

gtid_owned

此只读变量主要用于内部使用。其内容取决于其范围。

gtid_purged

gtid_purged 系统变量的全局值 (@@GLOBAL.gtid_purged) 是一个 GTID 集，包含服务器上已提交但服务器上任何二进制日志文件中都不存在的所有事务的 GTID。gtid_purged 是 gtid_executed 的一个子集。以下类别的 GTID 在 gtid_purged 中：

服务器启动时，gtid_purged 的全局值初始化为一组 GTID。有关如何计算此 GTID 集的信息，请参见 全局变量 gtid_purged。如果服务器上存在来自 MySQL 5.7.7 或更早版本的二进制日志，您可能需要在服务器的配置文件中设置 binlog_gtid_simple_recovery=FALSE 以生成正确的计算结果。有关此设置所需的具体情况，请参见 binlog_gtid_simple_recovery 的描述。

您必须具有 TRANSACTION_GTID_TAG 才能设置 gtid_purged。

发出 RESET BINARY LOGS AND GTIDS 会导致 gtid_purged 的值重置为空字符串。

您可以设置 gtid_purged 的值，以便在服务器上记录特定 GTID 集中的事务已应用，尽管它们不存在于服务器上的任何二进制日志中。此操作的一个示例用例是，当您在服务器上还原一个或多个数据库的备份时，但您没有服务器上包含事务的相关二进制日志。

有两种方法可以设置 gtid_purged 的值。您可以用您指定的 GTID 集替换 gtid_purged 的值，或者您可以将您指定的 GTID 集附加到 gtid_purged 已拥有的 GTID 集。如果服务器没有现有的 GTID，例如您正在使用现有数据库的备份进行配置的空服务器，则两种方法的结果相同。如果您正在还原与服务器上已存在的事务重叠的备份，例如使用 mysqldump（它包括服务器上所有事务的 GTID，即使转储是部分的）从源生成的局部转储替换损坏的表，则使用第一种方法替换 gtid_purged 的值。如果您正在还原与服务器上已存在的事务不相交的备份，例如使用来自两个不同服务器的转储配置多源副本，则使用第二种方法添加到 gtid_purged 的值。