binlog_gtid_simple_recovery

此变量控制在 MySQL 启动或重新启动时搜索 GTID 期间如何迭代二进制日志文件。在 MySQL 5.6.21 版本中，添加了这个变量 simplified_binlog_gtid_recovery，在 MySQL 5.6.23 版本中它被重命名为 binlog_gtid_simple_recovery.

时 binlog_gtid_simple_recovery=FALSE，迭代从最新的文件开始初始化 gtid_executed，并从最旧的文件开始初始化 gtid_purged。如果您有大量没有 GTID 事件的二进制日志文件，例如在 gtid_mode=OFF.

当 时 ，服务器在迭代填充和 binlog_gtid_simple_recovery=TRUE时不会打开两个以上的二进制日志 ，无论是在服务器重新启动期间还是在清除二进制日志时。 gtid_purgedgtid_executed

enforce_gtid_consistency

当此变量为真时，服务器通过仅允许执行那些可以以事务安全方式记录的语句来强制执行 GTID 一致性。您 必须先启用 GTID 一致性（通过启用 enforce_gtid_consistency），然后才能启动服务器 gtid_mode=ON；否则，启用 GTID 模式会失败并出现错误。您 可以（并且应该）在使用 之前启用 GTID 一致性gtid_mode，以测试系统是否准备好使用 GTID。

由于在为真时只能记录事务安全语句enforce_gtid_consistency，因此在这种情况下不能使用此处列出的操作：

该变量在运行时是只读的，必须在服务器启动时设置。

使用 时允许涉及临时表的非事务性 DML 语句 binlog_format=ROW，只要受语句影响的任何非事务性表都是临时表（缺陷 #14272672）。

在 MySQL 5.6 中，可以但不建议 在服务器 where 上 运行mysql_upgradegtid_mode=ON，因为 MySQL 系统表使用 MyISAM非事务性存储引擎。

此选项允许单个语句更新非事务表，主要用于mysql_install_db 和mysql_upgrade等程序。（漏洞 #14722659）

gtid_executed

当与全局范围一起使用时，此变量包含二进制日志中记录的所有事务集的表示。 这与和Executed_Gtid_Set的输出中列的值相同。 SHOW MASTER STATUSSHOW SLAVE STATUS

当与会话范围一起使用时，此变量包含在当前会话中写入缓存的一组事务的表示。

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

服务器启动时， @@GLOBAL.gtid_executed初始化为以下两组的并集：

此后，随着事务的执行，GTID 被添加到集合中。

发出RESET MASTER导致此变量的全局值（但不是会话值）重置为空字符串。除了由于RESET MASTER. 如果服务器关闭并删除所有二进制日志，该集也会被清除。

gtid_mode

此变量指定是否使用全局事务标识符 (GTID) 来标识事务。该变量在运行时是只读的，必须在服务器启动时设置。

使用 启动服务器gtid_mode=ON 要求服务器也使用 --log-bin、 --log-slave-updates和 --enforce-gtid-consistency 选项启动。

将此选项设置为OFF当二进制日志或中继日志中有 GTID 时，或者 ON当仍有匿名事务要执行时，会导致错误。

gtid_purged 和 的值在gtid_executed时不持久 gtid_mode=off。因此，更改gtid_mode为 后OFF，一旦清除所有包含 GTID 的二进制日志，这些变量的值将丢失。

gtid_next

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

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

gtid_next可以采用以下任何值：

gtid_mode如果是 ，则 设置此变量无效 OFF。

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

仅在 MySQL 5.6.11 中，您不能执行任何语句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.6.12 及更高版本中不禁止此类语句。（错误#16062608、错误#16715809、错误#69045）

gtid_owned

这个只读变量包含一个列表，其内容取决于其范围。当与会话范围一起使用时，该列表包含此客户端拥有的所有 GTID；当与全局范围一起使用时，它包含所有 GTID 及其所有者的列表。

gtid_purged

已从二进制日志中清除的所有事务的集合。这是 中交易集的一个子集 gtid_executed。

当服务器启动时，全局值 gtid_purged被初始化为 Previous_gtid_log_event最早的二进制日志包含的一组 GTID。当二进制日志被清除时， gtid_purged从现在已经成为最旧的二进制日志中重新读取。

要更新这个变量的值， gtid_mode必须是 ON， gtid_executed必须是空串，因此 gtid_purged也是空串。这可能发生在复制之前未启动时，或者复制之前未使用 GTID 时。

执行后SET gtid_purged，记下当前的二进制日志文件名，可以使用查看SHOW MASTER STATUS。如果服务器在这个文件被清除之前重新启动，那么你应该使用 binlog_gtid_simple_recovery=0 （5.6 中的默认值）来避免 gtid_purged或被 gtid_executed错误地计算。

发出RESET MASTER会导致此变量的值重置为空字符串。

simplified_binlog_gtid_recovery

此选项已弃用；希望在未来的 MySQL 版本中将其删除。使用该 binlog_gtid_simple_recovery 变量来控制 MySQL 在崩溃后如何遍历二进制日志文件。