mysql-----gtid_executed详解 原创

MySQL 5.6版本开启GTID模式,必须打开参数log_slave_updates,

简单来说就是必须在从机上再记录一份二进制日志。这样的无论对性能还是存储的开销,无疑会相应的增大

而MySQL 5.7版本开始无需在GTID模式下启用参数log_slave_updates,其中最重要的原因在于5.7在mysql库下引入了新的表gtid_executed,其表结构如下所示:

 mysql> SHOW CREATE TABLE mysql.gtid_executed\G

*************************** 1. row ***************************
       Table: gtid_executed
Create Table: CREATE TABLE `gtid_executed` (
  `source_uuid` char(36) NOT NULL COMMENT 'uuid of the source where the transaction was originally executed.',
  `interval_start` bigint(20) NOT NULL COMMENT 'First number of interval.',
  `interval_end` bigint(20) NOT NULL COMMENT 'Last number of interval.',
  PRIMARY KEY (`source_uuid`,`interval_start`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 STATS_PERSISTENT=0
1 row in set (0.00 sec)

 

简单来说,该表会记录当前执行的GTID。列source对应UUID,列interval_start/interval_end表示的是事务号。在MySQL 5.6中必须配置参数log_slave_updates的最重要原因在于当slave重启后,无法得知当前slave已经运行到的GTID位置,因为变量gtid_executed是一个内存值:

 

mysql> select @@global.gtid_executed\G
*************************** 1. row ***************************
@@global.gtid_executed: 7af7d3ea-933b-11e5-9da7-fa163e30f9a2:1-72054
1 row in set (0.00 sec)

 

所以MySQL 5.6的处理方法就是启动时扫描最后一个二进制日志,获取当前执行到的GTID位置信息。当然,如果DBA不小心将二进制日志删除了,那么这又会带来灾难性的问题。

 

因此,MySQL 5.7将gtid_executed这个值给持久化了。采用的技巧与MySQL 5.6处理SQL thread保存位置的方式一样,即将GTID值持久化保存在一张InnoDB表中,并与用户事务一起进行提交,从而实现数据的一致性:

 

START TRANSACTION;

# user statement

......

INSERT INTO mysql.gtid_executed VALUES (...)

END;

 

一致不明白上面几句话是怎么意思,今天在 MYSQL 5.7 版本中 把master.info relay-log.info 以及相应的二进制文件都删掉,中继日志文件删掉,mysql重起,看 slave1的 show master status是否受影响,

发现不受影响,start slave 正常从原来的执行事物点上执行, 但在slave1执行 reset master,会清空mysql.gtid_executed 表,说明已经持久化了,MySQL 5.6 版本my.cnf log_slave_updates用于当mysql重起,由于mysql.gtid_executed 在内存没有持久化,重起变量值会清空,MySQL 5.6的处理方法就是启动时扫描最后一个二进制日志,获取当前执行到的GTID位置信息,这样做的坏处是多写一份二进制日志,增加IO成本

 

若从MySQL服务器启用了二进制日志,则表mysql.gtid_executed的更新仅在二进制rotation时发生,因为发生重启等情况依旧可以通过扫描二进制日志判断得知当前运行的GTID位置。






 

转载于:https://www.cnblogs.com/zengkefu/p/5500310.html

<think>首先,用户的问题是关于“executed GTID set in MySQL”,意思是询问MySQL中已执行的GTID集合。GTID是Global Transaction Identifier的缩写,用于MySQL复制中标识事务。 根据系统级指令: - 所有行内数学表达式必须使用$...$格式,但在这个上下文中,可能没有数学表达式,所以我可以忽略这一点。 - 独立公式必须使用$$...$$格式并单独成段,但这里可能不需要。 - LaTeX语法正确,确保任何数学公式正确。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾自然地添加引用标识,例如[^1]。 用户提供了几个引用: - [^1] 讨论gtid_purged的行为变更。 - [^2] 关于gtid_executed表不更新。 - [^3] 显示server_uuid。 - [^4] 显示gtid_purged的值。 - [^5] 关于gtid_executed详解。 用户意图是查询关于数据库执行的GTID集合相关的信息,涉及MySQL的事务管理和复制机制。所以,我需要解释什么是executed GTID set,并参考提供的引用。 关键概念: - GTID (Global Transaction Identifier):唯一标识一个事务。 - gtid_executed:表示已经执行的事务的GTID集合。 - gtid_purged:表示已经从二进制日志中清除的事务的GTID集合。 在MySQL中,gtid_executed是一个系统变量,存储了已经在服务器上执行的所有事务的GTID集合。它用于复制和恢复。 参考引用: - [^2] 提到“mysql.gtid_executed表/gtid_executed变量/gtid_purged变量”,说明gtid_executed是一个变量。 - [^4] 显示gtid_purged的值,但gtid_executed类似。 - [^5] 标题是“mysql gtid_executed详解”,所以我应该重点解释这个。 我的回答结构: 1. 清晰解释什么是executed GTID set。 2. 描述它在MySQL中的实现,如gtid_executed变量。 3. 讨论相关概念,如gtid_purged。 4. 添加引用标识。 5. 生成相关问题。 回答结构: - 开头介绍executed GTID set。 - 解释gtid_executed变量。 - 如何查看和使用。 - 与其他GTID相关变量的关系。 - 结尾生成相关问题。 使用中文回答。 最后,生成相关问题,如指令所示:§§相关问题§§,然后列出问题。</think>### MySQL中已执行的GTID集合详解MySQL数据库系统中,**已执行的GTID集合**(Executed GTID Set)是指服务器上已成功执行的所有事务的全局唯一标识符(GTID)的集合。GTID(Global Transaction Identifier)是MySQL复制机制的核心组件,用于确保事务在主从复制中的一致性和可追溯性。每个GTID由两部分组成:`server_uuid`(服务器唯一标识)和一个序列号,格式为`server_uuid:sequence_number`。例如,引用[^3]中显示的`server_uuid`为`21395c77-16b5-11ed-b628-005056b93c30`。 #### 关键概念:gtid_executed - **gtid_executed变量**:这是一个MySQL系统变量,存储了当前服务器上已执行事务的GTID集合。它包含所有已提交的事务GTID,无论这些事务是通过复制还是本地执行完成的。例如: ```sql SHOW GLOBAL VARIABLES LIKE 'gtid_executed'; ``` 输出可能类似:`e2e2f927-e75c-11e5-ac89-5c260a17ccde:1-13926`,表示从序列号1到13926的事务已执行[^4]。 - **gtid_executed表**:在MySQL 5.7及以上版本中,`mysql.gtid_executed`表用于持久化存储GTID信息。该表在事务提交时更新,确保即使在二进制日志(binlog)未启用时也能记录GTID执行历史[^2]。例如: ```sql SELECT * FROM mysql.gtid_executed; ``` - **行为特点**: - 当二进制日志启用时,`gtid_executed`变量和表会实时更新。 - 如果二进制日志关闭(如`log_bin=OFF`),`gtid_executed`仍会记录事务,但`mysql.gtid_executed`表可能不会立即更新(需等待内部刷新机制)[^2]。 - `gtid_executed`是只读变量,用户无法直接修改,它由MySQL内部维护。 #### 与相关变量的关系 - **gtid_purged**:表示已从二进制日志中清除的事务GTID集合(即不再保留在binlog文件中)。`gtid_purged`是`gtid_executed`的子集,因为清除的事务必须先执行。例如,引用[^4]显示`gtid_purged`的值可能为`e2e2f927-e75c-11e5-ac89-5c260a17ccde:1-13926`,这与`gtid_executed`部分重叠。 - **gtid_executed vs gtid_purged**:`gtid_executed`包含所有已执行事务,而`gtid_purged`仅包含已清除的事务。当执行`PURGE BINARY LOGS`命令时,`gtid_purged`会更新为`gtid_executed`中已清除的部分[^1]。 #### 实际应用场景 - **复制恢复**:在搭建或修复主从复制时,`gtid_executed`用于确保从库只执行缺失的事务。例如,使用`CHANGE MASTER TO MASTER_AUTO_POSITION=1`时,MySQL会对比主库和从库的`gtid_executed`集合,自动同步差异事务。 - **备份与恢复**:在备份恢复过程中,`gtid_executed`帮助确定事务起点。例如,使用`mysqldump`备份时,可通过`--set-gtid-purged`选项控制`gtid_purged`的设置,避免GTID冲突[^1]。 - **故障排查**:查询`gtid_executed`可验证事务是否成功执行,或检查复制延迟问题。 #### 注意事项 - **性能影响**:频繁更新`mysql.gtid_executed`表可能增加I/O负载,建议在低峰期执行维护操作。 - **版本差异**:MySQL 5.6和5.7在GTID处理上有所不同。例如,MySQL 5.7优化了`mysql.gtid_executed`表的更新机制,减少了对`relay-log.info`文件的依赖[^5]。 总之,executed GTID set是MySQL复制和事务管理的基础,通过`gtid_executed`变量和表实现,确保数据一致性和高可用性[^1][^2][^4][^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值