本节中描述的 MySQL 服务器系统变量用于监视和控制全局事务标识符 (GTID)。有关其他信息,请参阅 第 17.1.3 节,“使用全局事务标识符进行复制”。
-
命令行格式 --binlog-gtid-simple-recovery[={OFF|ON}]系统变量 binlog_gtid_simple_recovery范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 ON此变量控制在 MySQL 启动或重新启动时搜索 GTID 期间如何迭代二进制日志文件。
When
binlog_gtid_simple_recovery=TRUE是 MySQL 8.0 中的默认值,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.0 之后),则在以下两种情况下,使用
binlog_gtid_simple_recovery=TRUE和gtid_executed可能gtid_purged会错误地初始化:- 最新的二进制日志是由 MySQL 5.7.5 或更早版本生成的,并且
gtid_mode是ON针对一些二进制日志的,但OFF针对的是最新的二进制日志。 - 在 MySQL 5.7.7 或更早版本上发出了一条
SET @@GLOBAL.gtid_purged语句,并且在该SET @@GLOBAL.gtid_purged语句时处于活动状态的二进制日志尚未被清除。
如果在任何一种情况下都计算了不正确的 GTID 集,即使服务器稍后重新启动,它仍然不正确
binlog_gtid_simple_recovery=FALSE。如果这些情况中的任何一种适用或可能适用于服务器,请binlog_gtid_simple_recovery=FALSE在启动或重新启动服务器之前进行设置。设置时 ,系统变量中 描述 的
binlog_gtid_simple_recovery=FALSE计算方法 将更改为迭代二进制日志文件,如下所示:gtid_executedgtid_purgedgtid_purged- 不是使用最新二进制日志文件中的值
Previous_gtids_log_event和 GTID 日志事件,而是从最新的二进制日志文件中进行gtid_executed迭代,并使用Previous_gtids_log_event找到值的第一个二进制日志文件中的值和任何 GTID 日志事件Previous_gtids_log_event。如果服务器最近的二进制日志文件没有 GTID 日志事件,例如如果gtid_mode=ON使用但服务器后来更改为gtid_mode=OFF,则此过程可能需要很长时间。 - 不是使用最旧的二进制日志文件中的值,而是
Previous_gtids_log_event从最旧的二进制日志文件中进行gtid_purged迭代,并使用Previous_gtids_log_event第一个找到非空Previous_gtids_log_event值或至少一个 GTID 日志事件的二进制日志文件中的值(表示 GTID 的使用从那时开始)。如果服务器的旧二进制日志文件没有 GTID 日志事件,例如,如果gtid_mode=ON最近才在服务器上设置,则此过程可能需要很长时间。
- 最新的二进制日志是由 MySQL 5.7.5 或更早版本生成的,并且
-
命令行格式 --enforce-gtid-consistency[=value]系统变量 enforce_gtid_consistency范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 OFF有效值 OFF``ON``WARN根据此变量的值,服务器通过只允许执行可以使用 GTID 安全记录的语句来强制执行 GTID 一致性。在启用基于 GTID 的复制之前, 您 必须将此变量设置为 。
ONenforce_gtid_consistency可以配置 的值为 :OFF:允许所有事务违反 GTID 一致性。ON: 不允许任何事务违反 GTID 一致性。WARN:允许所有事务违反 GTID 一致性,但在这种情况下会生成警告。
--enforce-gtid-consistency仅当对语句进行二进制日志记录时才会生效。如果服务器上禁用了二进制日志记录,或者如果语句由于被过滤器删除而未写入二进制日志,则不会检查或强制未记录语句的 GTID 一致性。enforce_gtid_consistency当设置为时, 只能记录可以使用 GTID 安全语句记录 的语句ON,因此此处列出的操作不能与此选项一起使用:CREATE TEMPORARY TABLE或DROP TEMPORARY TABLE交易中的陈述。- 更新事务和非事务表的事务或语句。如果所有非事务性表都是临时的 ,则在与事务性 DML 相同的事务或同一语句中允许非事务性 DML 是一个例外 。
CREATE TABLE ... SELECT语句,在 MySQL 8.0.21 之前。从 MySQL 8.0.21 开始,CREATE TABLE ... SELECT支持 atomic DDL 的存储引擎允许使用语句。
有关更多信息,请参阅 第 17.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_VAR提示适用不 类型 细绳 单元 一组 GTID 当与全局范围一起使用时,此变量包含在服务器上执行的所有事务集的表示以及已由 语句设置的 GTID。这与和 的输出中列 的值相同 。此变量的值是一个 GTID 集,有关更多信息,请参阅 GTID 集。
SETgtid_purgedExecuted_Gtid_SetSHOW MASTER STATUSSHOW REPLICA STATUS当服务器启动时,
@@GLOBAL.gtid_executed被初始化。binlog_gtid_simple_recovery有关如何迭代二进制日志以填充的更多信息,请参阅gtid_executed。然后在执行事务或执行任何 语句时将 GTID 添加到集合中。SETgtid_purged在任何给定时间可以在二进制日志中找到的事务集等于
GTID_SUBTRACT(@@GLOBAL.gtid_executed, @@GLOBAL.gtid_purged); 也就是说,对于二进制日志中尚未清除的所有事务。发出
RESET MASTER会导致此变量的全局值(但不是会话值)重置为空字符串。GTID 不会从该集合中移除,除非该集合由于RESET MASTER.在一些较旧的版本中,此变量也可以与会话范围一起使用,其中它包含在当前会话中写入缓存的事务集的表示。会话范围现在已弃用。
-
gtid_executed_compression_period命令行格式 --gtid-executed-compression-period=#系统变量 gtid_executed_compression_period范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值(≥ 8.0.23) 0默认值 (≤ 8.0.22) 1000最小值 0最大值 4294967295mysql.gtid_executed每次处理这么多事务时 压缩表。在服务器上启用二进制日志记录时,不使用此压缩方法,而是mysql.gtid_executed在每次二进制日志轮换时压缩表。当服务器上禁用二进制日志时,压缩线程会休眠,直到执行了指定数量的事务,然后唤醒以执行mysql.gtid_executed表压缩。将此系统变量的值设置为 0 意味着线程永远不会唤醒,因此不使用这种显式压缩方法。相反,压缩会根据需要隐式发生。从 MySQL 8.0.17 开始,事务由与非 事务分开的进程
InnoDB写入表。如果服务器混合了 事务和非事务,则由此系统变量控制的压缩会干扰此进程的工作,并可能显着减慢它。因此,从该版本开始,建议您设置 为 0。mysql.gtid_executed``InnoDB``InnoDB``InnoDBgtid_executed_compression_period从 MySQL 8.0.23 开始,
InnoDB非InnoDB事务由同一个进程写入mysql.gtid_executed表,gtid_executed_compression_period默认值为 0。有关更多信息,请参阅 mysql.gtid_executed 表压缩 。
-
命令行格式 --gtid-mode=MODE系统变量 gtid_mode范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 OFF有效值 OFF``OFF_PERMISSIVE``ON_PERMISSIVE``ON控制是否启用基于 GTID 的日志记录以及日志可以包含的事务类型。您必须具有足够的权限才能设置全局系统变量。请参见 第 5.1.9.1 节,“系统变量权限”。
enforce_gtid_consistency必须设置为ON才能设置gtid_mode=ON。在修改此变量之前,请参阅 第 17.1.4 节,“更改在线服务器上的 GTID 模式”。记录的事务可以是匿名的或使用 GTID。匿名事务依赖二进制日志文件和位置来识别特定事务。GTID 事务具有用于引用事务的唯一标识符。不同的模式是:
OFF: 新的和复制的事务都必须是匿名的。OFF_PERMISSIVE: 新交易是匿名的。复制的交易可以是匿名交易或 GTID 交易。ON_PERMISSIVE: 新交易是 GTID 交易。复制的交易可以是匿名交易或 GTID 交易。ON:新事务和复制事务都必须是 GTID 事务。
从一个值到另一个值的更改一次只能是一个步骤。例如,如果
gtid_mode当前设置为OFF_PERMISSIVE,则可以更改为OFF或ON_PERMISSIVE但不能更改为ON。无论 的值如何,
gtid_purged和 的 值都是持久的。因此,即使在更改 的值之后 ,这些变量也包含正确的值。gtid_executedgtid_modegtid_mode -
系统变量 gtid_next范围 会议 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 AUTOMATIC有效值 AUTOMATIC``ANONYMOUS``UUID:NUMBER该变量用于指定是否以及如何获取下一个 GTID。
设置此系统变量的会话值是一项受限操作。会话用户必须具有
REPLICATION_APPLIER特权(请参阅第 17.3.3 节,“复制特权检查”)或足以设置受限会话变量的特权(请参阅 第 5.1.9.1 节,“系统变量特权”)。gtid_next可以采用以下任何值:AUTOMATIC:使用下一个自动生成的全局事务 ID。ANONYMOUS:事务没有全局标识符,仅由文件和位置标识。- 格式 为*
UUID: 的全局事务 ID 。NUMBER*
上述哪些选项有效取决于 的设置
gtid_mode,有关详细信息,请参阅 第 17.1.4.1 节,“复制模式概念”。gtid_mode如果是 ,则设置此变量无效OFF。在此变量设置为
UUID😗NUMBER*并且事务已提交或回滚后,SET GTID_NEXT必须在任何其他语句之前再次发出显式语句。DROP TABLE或者DROP TEMPORARY TABLE当用于非临时表与临时表的组合,或使用事务性存储引擎的临时表与使用非事务性存储引擎的临时表的组合时,会因显式错误而失败。 -
系统变量 gtid_owned范围 全球, 会话 动态的 不 SET_VAR提示适用不 类型 细绳 单元 一组 GTID 此只读变量主要供内部使用。它的内容取决于它的范围。
- 与全局范围一起使用时,
gtid_owned保存服务器上当前正在使用的所有 GTID 的列表,以及拥有它们的线程的 ID。此变量主要用于多线程副本检查事务是否已在另一个线程上应用。应用程序线程在处理事务时始终拥有事务的 GTID,因此@@global.gtid_owned在处理期间显示 GTID 和所有者。当事务已提交(或回滚)时,应用程序线程释放 GTID 的所有权。 - 与会话范围一起使用时,
gtid_owned保存一个当前由该会话使用和拥有的 GTID。当客户端通过设置为事务显式分配 GTID 时,此变量主要用于测试和调试 GTID 的使用gtid_next。在这种情况下,@@session.gtid_owned在客户端处理事务时一直显示 GTID,直到事务被提交(或回滚)。当客户端完成处理事务时,变量被清除。如果gtid_next=AUTOMATIC用于会话,gtid_owned仅在事务的提交语句执行期间短暂填充,因此无法从相关会话中观察到,尽管如果@@global.gtid_owned在正确的位置读取它会列出。如果您需要跟踪会话中客户端处理的 GTID,您可以启用由session_track_gtids系统变量控制的会话状态跟踪器。
- 与全局范围一起使用时,
-
系统变量 gtid_purged范围 全局 动态的 是的 SET_VAR提示适用不 类型 细绳 单元 一组 GTID gtid_purged系统变量 ( ) 的全局值@@GLOBAL.gtid_purged是一个 GTID 集,由服务器上已提交但不存在于服务器上的任何二进制日志文件中的所有事务的 GTID 组成。gtid_purged是 的子集gtid_executed。以下类别的 GTID 位于gtid_purged:- 在副本上禁用二进制日志记录的情况下提交的复制事务的 GTID。
- 写入二进制日志文件的事务的 GTID,现在已被清除。
- 由语句显式添加到集合中的 GTID
SET @@GLOBAL.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 仅在服务器实例上可用,最多可用于有符号 64 位整数的非负值数量(2 的 63 次幂,负 1)。如果您将 的值设置为
gtid_purged接近此限制的数字,则后续提交可能会导致服务器用完 GTID 并执行 指定的操作binlog_error_action。从 MySQL 8.0.23 开始,当服务器实例接近限制时会发出警告消息。从 MySQL 8.0 开始,有两种方法可以设置
gtid_purged. 您可以将 的值替换为gtid_purged您指定的 GTID 集,也可以将您指定的 GTID 集附加到 已持有的 GTID 集gtid_purged。如果服务器没有现有的 GTID,例如您正在使用现有数据库的备份配置的空服务器,则两种方法具有相同的结果。如果您正在恢复与服务器上已经存在的事务重叠的备份,例如用使用mysqldump生成的源的部分转储替换损坏的表(包括服务器上所有事务的 GTID,即使转储是部分的),请使用第一种方法替换gtid_purged. 如果您要恢复的备份与服务器上已经存在的事务不相交,例如使用来自两个不同服务器的转储来供应多源副本,请使用第二种方法添加gtid_purged.-
要将 的值替换为
gtid_purged您指定的 GTID 集,请使用以下语句:SET @@GLOBAL.gtid_purged = 'gtid_set'gtid_set必须是 的当前值的超集gtid_purged,并且不能与 相交gtid_subtract(gtid_executed,gtid_purged)。换句话说,新的 GTID 集 必须包含任何已存在 的 GTIDgtid_purged,并且 不得gtid_executed包含 尚未清除的任何 GTID 。gtid_set也不能包含 中的任何 GTID,@@global.gtid_owned即当前正在服务器上处理的事务的 GTID。结果是 的全局值
gtid_purged被设置为等于gtid_set,并且 的值gtid_executed成为 的gtid_set和 的前一个值的并集gtid_executed。 -
要将您指定的 GTID 集附加到
gtid_purged,请在 GTID 集之前使用以下带有加号 (+) 的语句:SET @@GLOBAL.gtid_purged = '+gtid_set'gtid_set不得与 的当前值相交gtid_executed。换句话说,新的 GTID 集不得包含任何 GTIDgtid_executed,包括已经在 中的事务gtid_purged。gtid_set也不能包含 中的任何 GTID,@@global.gtid_owned即当前正在服务器上处理的事务的 GTID。结果是
gtid_set被添加到gtid_executed和gtid_purged中。
笔记
如果服务器上存在 MySQL 5.7.7 或更早版本的任何二进制日志(例如,在将旧服务器升级到 MySQL 8.0 之后),在发出SET @@GLOBAL.gtid_purged语句后,您可能需要 binlog_gtid_simple_recovery=FALSE 在服务器的配置文件中进行设置,然后再重新启动服务器,否则gtid_purged可能计算不正确。binlog_gtid_simple_recovery有关需要此设置的情况的详细信息, 请参阅说明 。




