mysql全局事务变量GTID

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?始终可以安全使用。

使用?binlog_gtid_simple_recovery=TRUE,?gtid_executed和?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_executedgtid_purgedgtid_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 一致性。

有关更多信息，请参阅?第 2.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会导致该变量的全局值（但不是会话值）重置为空字符串。除了由于 原因而清除该集合时，GTID 不会以其他方式从该集合中删除?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_execulated 表压缩。

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

gtid_mode

控制是否启用基于 GTID 的日志记录以及日志可以包含的事务类型。--gtid-mode在 MySQL 5.7.6 之前，此变量是只读的，并且仅在服务器启动时使用 。在 MySQL 5.7.5 之前，使用 启动服务器?--gtid-mode=ON要求服务器也使用?--log-bin和?--log-slave-updates选项启动。从 MySQL 5.7.5 开始，这不再是一个要求。请参阅?mysql.gtid_execulated 表。

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

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

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

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

gtid_next

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

设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参阅?系统变量权限。

gtid_next可以采用以下任意值：

上述哪个选项准确取决于 的设置gtid_mode，?有关更多信息，请参阅第 2.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_purged为您指定的 GTID 集，请使用以下语句：

SET @@GLOBAL.gtid_purged = 'gtid_set'