binlog_gtid_simple_recovery

该变量控制MySQL启动或重新启动时在搜索GTIDs时如何迭代二进制日志文件。

当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.3时），则binlog_gtid_simple_recovery=TRUE可能会导致gtid_executed和gtid_purged在以下两种情况下初始化不正确：

如果在这两种情况下计算出错误的GTID集，即使服务器后来以binlog_gtid_simple_recovery=FALSE重新启动，GTID集仍将保持不正确。如果这两种情况适用或可能适用服务器，请在启动或重新启动服务器之前将binlog_gtid_simple_recovery设置为FALSE。

当binlog_gtid_simple_recovery=FALSE时，gtid_executed和gtid_purged的计算方法将更改为迭代二进制日志文件，如gtid_purged系统变量所述。

enforce_gtid_consistency

根据这个变量的值，服务器强制 GTID 一致性，仅允许执行可以安全地使用 GTID 记录的语句。你 必须 在启用基于 GTID 的复制之前将这个变量设置为 ON。

可以将 enforce_gtid_consistency 配置为以下值：

--enforce-gtid-consistency 只在语句被记录到二进制日志时生效。如果二进制日志记录被禁用或语句被过滤器删除，那么 GTID 一致性不会被检查或强制。

只有可以使用 GTID 安全语句记录的语句可以被记录，当 enforce_gtid_consistency 设置为 ON 时，因此以下操作不能与这个选项一起使用：

有关更多信息，请参阅 第 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

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

当服务器启动时，@@GLOBAL.gtid_executed 被初始化。更多信息请参阅 binlog_gtid_simple_recovery，了解二进制日志如何被迭代以填充 gtid_executed。然后，GTIDs 将被添加到集合中，因为事务被执行，或者如果任何 SET gtid_purged 语句被执行。

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

发出 RESET BINARY LOGS AND GTIDS 将导致该变量被重置为空字符串。GTIDs 不会从该集合中删除，除非是由于 RESET BINARY LOGS AND GTIDS。

gtid_executed_compression_period

每处理多少事务后压缩 mysql.gtid_executed 表。当服务器上启用二进制日志记录时，不使用这种压缩方法，而是每次二进制日志轮换时压缩 mysql.gtid_executed 表。当服务器上禁用二进制日志记录时，压缩线程休眠，直到执行了指定数量的事务，然后醒来执行 mysql.gtid_executed 表的压缩。将该系统变量的值设置为 0 意味着线程永远不会醒来，因此不使用这种显式压缩方法。相反，压缩将隐式地如有必要进行。

InnoDB 事务由单独的进程写入 mysql.gtid_executed 表，而非 InnoDB 事务。如果服务器混合了 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 节，“系统变量权限”。enforce_gtid_consistency 必须设置为 ON，然后才能设置 gtid_mode=ON。在修改该变量之前，请参阅 第 19.1.4 节，“在线服务器上的 GTID 模式更改”。

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

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

无论 gtid_mode 的值如何，gtid_purged 和 gtid_executed 的值将保持不变。因此，即使更改了 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:标签: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 的描述，以了解需要这种设置的情况。

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

您可以设置 gtid_purged 的值，以便在服务器上记录某个 GTID 集中的事务已经被应用，尽管它们不在服务器上的任何二进制日志中。例如，当您从备份中恢复一个或多个数据库到服务器上，但您没有包含这些事务的相关二进制日志时。

有两种方法可以设置 gtid_purged 的值。您可以将 gtid_purged 的值替换为指定的 GTID 集，或者将指定的 GTID 集追加到 gtid_purged 的值中。如果服务器没有现有的 GTIDs，例如空服务器，您正在使用备份来 provision 数据库，那么这两种方法都将产生相同的结果。如果您正在恢复一个部分备份，例如使用 mysqldump 生成的备份（包括服务器上的所有事务的 GTIDs，即使备份是部分的），那么使用第一种方法替换 gtid_purged 的值。如果您正在恢复一个不相交的备份，例如使用来自两个不同服务器的备份来 provision 多源副本，那么使用第二种方法追加到 gtid_purged 的值中。