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 9.0 之后），并且 binlog_gtid_simple_recovery=TRUE，则在以下两种情况下 gtid_executed 和 gtid_purged 可能会被错误地初始化

如果在这两种情况下计算出不正确的 GTID 集，则即使服务器随后在 binlog_gtid_simple_recovery=FALSE 的情况下重启，它仍然是不正确的。如果上述两种情况之一适用于服务器或可能适用于服务器，请在启动或重启服务器之前将 binlog_gtid_simple_recovery=FALSE 设置为 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 安全语句记录的语句才能被记录，因此以下列出的操作不能与该选项一起使用

有关更多信息，请参阅 第 19.1.3.7 节，“使用 GTID 进行复制的限制”。

在 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 集。

当服务器启动时，@@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 表压缩。

gtid_mode

控制是否启用基于 GTID 的日志记录以及日志可以包含哪种类型的事务。您必须具有足够的权限来设置全局系统变量。参阅 第 7.1.9.1 节，“系统变量权限”。在您设置 gtid_mode=ON 之前，必须将 enforce_gtid_consistency 设置为 ON。在修改此变量之前，请参阅 第 19.1.4 节，“在联机服务器上更改 GTID 模式”。

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

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

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

gtid_next

此变量用于指定是否以及如何获取下一个 GTID（请参阅 第 19.1.3 节，“使用全局事务标识符进行复制”）。

设置此系统变量的会话值是一个受限操作。会话用户必须拥有 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 的值添加 GTID 集。