写点什么

MySQL 基于 GTID 复制实现的工作原理

用户头像
云流
关注
发布于: 1 小时前

背景

MySQL 从 5.6 版本引入了 GTID 的复制模式.GTID (Global Transaction IDentifier) 是全局事务标识。它具有全局唯一性,一个事务对应一个 GTID。唯一性不仅限于主服务器,GTID 在所有的从服务器上也是唯一的。一个 GTID 在一个服务器上只执行一次,从而避免重复执行导致数据混乱或主从不一致。

在传统的复制里面,当发生故障需要主从切换时,服务器需要找到 binlog 和 pos 点,然后将其设定为新的主节点开启复制。相对来说比较麻烦,也容易出错。在 MySQL 5.6 里面,MySQL 会通过内部机制自动匹配 GTID 断点,不再寻找 binlog 和 pos 点。我们只需要知道主节点的 ip,端口,以及账号密码就可以自动复制。


GTID 的组成部分:

GDIT 由两部分组成:GTID = source_id:transaction_id。 其中 source_id 是产生 GTID 的服务器,即是 server_uuid,在第一次启动时生成(sql/mysqld.cc: generate_server_uuid()),并保存到 DATADIR/auto.cnf 文件里。transaction_id 是序列号(sequence number),在每台 MySQL 服务器上都是从 1 开始自增长的顺序号,是事务的唯一标识。例如:3E11FA47-71CA-11E1-9E33-C80AA9429562:23 GTID 的集合是一组 GTIDs,可以用 source_id+transaction_id 范围表示,例如:3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 复杂一点的:如果这组 GTIDs 来自不同的 source_id,各组 source_id 之间用逗号分隔;如果事务序号有多个范围区间,各组范围之间用冒号分隔,例如:3E11FA47-71CA-11E1-9E33-C80AA9429562:23,3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

GTID 如何产生:

GTID 的生成受 GTID_NEXT 控制。

在主服务器上,GTID_NEXT 默认值是 AUTOMATIC,即在每次事务提交时自动生成 GTID。它从当前已执行的 GTID 集合(即 gtid_executed)中,找一个大于 0 的未使用的最小值作为下个事务 GTID。同时在实际的更新事务记录之前,将 GTID 写入到 binlog(set GTID_NEXT 记录)。 在 Slave 上,从 binlog 先读取到主库的 GTID(即 get GTID_NEXT 记录),而后执行的事务采用该 GTID。

GTID 的工作原理:

GTID 在所有主从服务器上都是不重复的。所以所有在从服务器上执行的事务都可以在 bnlog 找到。一旦一个事务提交了,与拥有相同 GTID 的后续事务都会被忽略。这样可以保证从服务器不会重复执行同一件事务。

当使用 GTID 时,从服务器不需要保留任何非本地数据。使用数据都可以从 replicate data stream。从 DBA 和开发者的角度看,从服务器无保留 file-offset pairs 以决定如何处理主从服务器间的数据流。

GTID 的生成和使用由以下几步组成:

  • 主服务器更新数据时,会在事务前产生 GTID,一同记录到 binlog 日志中。

  • binlog 传送到从服务器后,被写入到本地的 relay log 中。从服务器读取 GTID,并将其设定为自己的 GTID(GTID_NEXT 系统)。

  • sql 线程从 relay log 中获取 GTID,然后对比从服务器端的 binlog 是否有记录。

  • 如果有记录,说明该 GTID 的事务已经执行,从服务器会忽略。

  • 如果没有记录,从服务器就会从 relay log 中执行该 GTID 的事务,并记录到 binlog。

GTID 相关的变量

GTID_NEXT:

SESSION 级别变量,表示下一个将被使用的 GTID。

  • Scope : Session

  • Dynamic : Yes

  • Type : Enumeration

  • Default Value : AUTOMATIC

  • Valid Values :

-- AUTOMATIC:使用自动产生的下一个GTID。-- ANONYMOUS:事务没有GTID,只使用 file and position 作为标识。-- UUID:NUMBER:GTID in UUID:NUMBER format.
复制代码

GTID_MODE:

Log 是否使用 GTID 或使用 anonymous。anonymous transaction 用 binlog file 和 position 来标识事务。

  • Scope : Global

  • Dynamic : Yes

  • Type : Enumeration

  • Default Value : OFF

  • Valid Values

-- OFF:新的和复制事务都使用anonymous。-- OFF_PERMISSIVE:新的事务都使用anonymous,而复制事务可以使用GTID或anonymous-- ON_PERMISSIVE:复制事务都使用anonymous,而新事务可以使用GTID或anonymous。-- ON: 新的和复制事务都使用GTID
复制代码

GTID_EXECUTED:

包含已经在该实例上执行过的事务; 执行 RESET MASTER 会将该变量置空; 我们还可以通过设置 GTID_NEXT 在执行一个空事务,来影响 GTID_EXECUTED。使用 SHOW MASTER STATUS and SHOW SLAVE STATUS,其中 Executed_Gtid_Set 会显示 GTID_EXECUTED 里的 GTIDs。5.7.7 之前,GTID_EXECUTED 可以是 seesion 变量。它包含当前 session 写入缓存的一组事务。

  • Scope : Global, Session

  • Dynamic : No

  • Type : String

GTID_PURGED:

已经被删除了 binlog 的事务,它是 GTID_EXECUTED 的子集,只有在 GTID_EXECUTED 为空时才能设置该变量,修改 GTID_PURGED 会同时更新 GTID_EXECUTED 和 GTID_PURGED 的值。

  • Scope : Global

  • Dynamic : Yes

  • Type : String

GTID_OWNED:

表示正在执行的事务的 GTID 以及其对应的线程 ID。

  • Scope : Global, Session

  • Dynamic : No

  • Type : String

如果 GDIT_OWNED 是全局变量,它包含所有当前服务器上正在使用的 GTIDs 和使用它们的线程 IDs。这个变量主要用于多线程从服务器复制,从而可以查看一个事务是否已经被另一个线程处理。这个线程会拥有所处理事务的 ownership。@@global.grid_owned 会显示出 GTID 和它的 owner。当事务处理完成,线程会释放 ownership. 如果 GDIT_OWNED 是 session 变量,它包含一个 seesion 正在使用的 GTID。这个变量对测试和 debug 会很有帮助。

GTID Auto-Positioning 实现

当我们使用 GTID 模式搭建主从时使用 MASTER_AUTO_POSITION=1 的时候.MySQL 内部是怎么处理的呢?

从库:

在连接到主库的时候主库会发送自身已经具有或者执行过的GTID set 也就是通过命令select @@GLOBAL.gtid_executed
复制代码

主库:

主库在接受到从库的gtid set之后.会去自己的binlog 文件中查找这个gtid set之后的gtid发送给从库.首先会找到一个合适的binlog文件开始确定gtid set.在每个binlog文件的头部都会存有Previous_gtids_log_event这个数据.通过这个数据确定到对应的binlog文件.然后开始发送对应的gtid到从库执行
复制代码

总结

这篇文章主要分享了 MySQL GTID 的复制原理实现


来源:https://www.toutiao.com/a6999245812274528800/?log_from=489b73c10ef75_1629870171264

用户头像

云流

关注

还未添加个人签名 2020.09.02 加入

还未添加个人简介

评论

发布
暂无评论
MySQL基于GTID复制实现的工作原理