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 或更高版本生成的，并且您使用的是 MySQL 5.7.8 或更高版本， binlog_gtid_simple_recovery=TRUE 则始终可以安全使用。

With binlog_gtid_simple_recovery=TRUE, gtid_executedand gtid_purged可能会在以下两种情况下被错误初始化：

如果在任何一种情况下计算出的 GTID 集都不正确，即使稍后使用 重新启动服务器，它仍然不正确 binlog_gtid_simple_recovery=FALSE。如果这些情况之一适用于服务器，请 binlog_gtid_simple_recovery=FALSE 在启动或重新启动服务器之前设置。要检查第二种情况，如果您使用的是 MySQL 5.7.7 或更早版本，请在发出SET @@GLOBAL.gtid_purged 语句后记下当前二进制日志文件名，可以使用SHOW MASTER STATUS. 如果服务器在这个文件被清除之前重新启动，那么你应该设置 binlog_gtid_simple_recovery=FALSE.

binlog_gtid_simple_recovery=FALSE 设置后，系统变量中描述的计算方法 将更 改为gtid_executed迭代 gtid_purged二进制 日志gtid_purged文件，如下所示：

在 MySQL 5.7.5 版本中，添加了这个变量 simplified_binlog_gtid_recovery，在 MySQL 5.7.6 版本中它被重命名为 binlog_gtid_simple_recovery.

enforce_gtid_consistency

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

enforce_gtid_consistency可以配置为 的值 是：

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

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

有关详细信息，请参阅 第 16.1.3.6 节，“使用 GTID 进行复制的限制”。

在 MySQL 5.7.6 之前，布尔值 enforce_gtid_consistency 默认为OFF. 为了保持与以前版本的兼容性，在 MySQL 5.7.6 中，枚举默认为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。这与和 的输出中列 的值相同 。此变量的值是一个 GTID 集，有关更多信息，请参阅 GTID 集。 SET gtid_purgedExecuted_Gtid_SetSHOW MASTER STATUSSHOW SLAVE STATUS

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

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

发出RESET MASTER导致此变量的全局值（但不是会话值）重置为空字符串。除了由于 RESET MASTER.

在 MySQL 5.7.7 之前，这个变量也可以与会话范围一起使用，它包含在当前会话中写入缓存的一组事务的表示。会话范围在 MySQL 5.7.7 中已弃用。

gtid_executed_compression_period

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

有关详细信息，请参阅 mysql.gtid_executed 表压缩 。

该变量在 MySQL 5.7.5 版中添加， executed_gtids_compression_period并在 MySQL 5.7.6 版中重命名为 gtid_executed_compression_period.

gtid_mode

控制是否启用基于 GTID 的日志记录以及日志可以包含的事务类型。在 MySQL 5.7.6 之前，这个变量是只读的，只能 --gtid-mode在服务器启动时使用。在 MySQL 5.7.5 之前，启动服务器 --gtid-mode=ON需要同时使用 --log-bin和 --log-slave-updates选项启动服务器。从 MySQL 5.7.5 开始，这不再是必需的。参见 mysql.gtid_executed 表。

MySQL 5.7.6 允许动态设置此变量。您必须具有足够的权限才能设置全局系统变量。请参阅第 5.1.8.1 节，“系统变量权限”。 enforce_gtid_consistency必须设置为ON才能设置 gtid_mode=ON。在修改此变量之前，请参阅 第 16.1.4 节，“更改在线服务器上的复制模式”。

MySQL 5.7.6 及更高版本中记录的事务可以是匿名的或使用 GTID。匿名交易依靠二进制日志文件和位置来识别特定交易。GTID 事务具有用于引用事务的唯一标识符。MySQL 5.7.6 中添加的OFF_PERMISSIVEand ON_PERMISSIVE模式允许在拓扑中混合使用这些事务类型。现在的不同模式是：

从一个值到另一个值的更改一次只能是一个步骤。例如，如果 gtid_mode当前设置为 OFF_PERMISSIVE，则可以更改为 OFF或ON_PERMISSIVE但不能更改为ON。

在 MySQL 5.7.6 及更高版本中， 无论 的值如何， gtid_purged和 的值都是持久的。因此，即使在更改 的值之后 ，这些变量仍包含正确的值。在 MySQL 5.7.5 及更早版本中， 和 的值 在 . 因此，更改为 后，一旦清除所有包含 GTID 的二进制日志，这些变量的值将丢失。 gtid_executedgtid_modegtid_modegtid_purgedgtid_executedgtid_mode=OFFgtid_modeOFF

gtid_next

该变量用于指定是否以及如何获取下一个 GTID。

设置这个系统变量的会话值是一个受限的操作。会话用户必须具有足以设置受限会话变量的权限。请参阅 第 5.1.8.1 节，“系统变量权限”。

gtid_next可以采用以下任何值：

上述选项中哪些选项有效取决于 的设置gtid_mode，请参阅 第 16.1.4.1 节，“复制模式概念”以获取更多信息。gtid_mode如果是 ，则设置此变量无效 OFF。

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

在 MySQL 5.7.5 及更高版本中，DROP TABLE或 DROP TEMPORARY TABLE在非临时表与临时表的组合上使用时失败并出现显式错误，或者在使用事务存储引擎的临时表与使用非事务存储引擎的临时表的组合上使用时失败。在 MySQL 5.7.5 之前，当 GTID 启用但未启用gtid_next时 AUTOMATIC，DROP TABLE在与这些表组合中的任何一个一起使用时无法正常工作。（漏洞 #17620053）

在 MySQL 5.7.1 中，您不能执行任何语句 CHANGE MASTER TO, START SLAVE, STOP SLAVE, REPAIR TABLE, OPTIMIZE TABLE, ANALYZE TABLE, CHECK TABLE, CREATE SERVER, ALTER SERVER, DROP SERVER, CACHE INDEX, LOAD INDEX INTO CACHE, FLUSH, 或 RESETwhen gtid_next设置为除AUTOMATIC;以外的任何值 在这种情况下，语句会因错误而失败。MySQL 5.7.2 及更高版本中不禁止此类语句 。（错误#16062608、错误#16715809、错误#69045）（错误#16062608）

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 MASTER导致 的值gtid_purged被重置为空字符串。

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

gtid_purged在 MySQL 5.7 中，只有当 是空字符串时才 可以更新值 gtid_executed，因此 gtid_purged是空字符串。当复制之前没有启动，或者复制之前没有使用 GTID 时，就会出现这种情况。在 MySQL 5.7.6 之前， gtid_purged也只有在gtid_mode=ON. 在 MySQL 5.7.6 及更高版本中， gtid_purged无论 gtid_mode.

要用您指定的 GTID 集替换 的值， gtid_purged请使用以下语句：

SET @@GLOBAL.gtid_purged = 'gtid_set'