开发者社区> db匠> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

MySQL内核月报 2014.09-MySQL· 限制改进·GTID和升级

简介:
+关注继续查看

GTID 资料

MySQL 5.6 引入了global transaction identifiers (GTIDs,全局事务ID)的特性,这一特性是用来解决主从复制(replication)场景下的一些问题,GTID 只存在于 binlog 中,数据库中是没有的。

要了解 GTID 的话,官方文档是一定要看的,另外再推荐推荐三篇 Oracle 同学写的文章(需爬墙):

  1. Failover and Flexible Replication Topologies in MySQL 5.6
  2. Advanced use of Global Transaction Identifiers
  3. Flexible Fail-over Policies Using MySQL and Global Transaction Identifiers
  4. 有兴趣的话也可以看下 GTID 的 worklog WL#3548

升级遇到的问题

GTID 能很好的解决 failover 问题,做到主库切换自动化,减轻 DBA 同学的负担,但是这个前提是所有的 MySQL 实例都是 5.6,如果线上实例是 5.5 的,必须全部升到 5.6 才行,而目前官方并没有提供平滑的 5.5 升级到 5.6 GTID 的方式,中间必须要有一个实例重启过程,这是由 GTID 目前的实现方式决定的:

  • 限制1. GTID 模式实例和非GTID模式实例是不能进行复制的,要求非常严格,一刀切,要么都是GTID,要么都不是
  • 限制2. gtid_mode 是只读的,要改变状态必须1)关闭实例、2)修改配置文件、3) 重启实例


在这种条件要求下,我们来看下线上实例从 5.5 升级到 5.6 会有什么问题,为了保证业务不中断,升级过程一直要有实例对外提供服务,因此升级方式是创建一个新的 5.6 实例,从5.5同步数据,然后业务切换到 5.6。

为了描述方便,做如下假设:

实例A
5.5 版本的,目前业务用的数据库
实例B
5.6 版本的,数据迁移的目标

迁移步骤如下:

  1. 用热备份工具如 Percona XtraBackup 将 A 数据备份然后导入到B
  2. B 用非 GTID 模式和 5.5 同步数据,这时用的是传统的基于文件位置的复制
  3. B和A同步的差不多的时候,在 A 上设 read_only,等 B 同步完成,假设同步完后时间点为 t1
  4. 关闭 B,修改参数开启GTID,重启B
  5. 将业务的数据操作指向B,假设这个时间点为 t2
  6. B 开始提供服务,迁移完毕

在上面的步骤中,t1 到 t2 的时间段内相当于数据库服务不可用,整个数据库停掉重启,这对线上业务来说是不可接受的,上面是用单个实例A和实例B说明问题,同样可以扩展到集群A和集群B。

gtid_mode 的取值范围除了 OFF 和 ON 这两个值外,还有 UPGRADE_STEP_1和UPGRADE_STEP_2,目前后2者并不支持,不过从名字上看应该是为了升级预留的,但是目前并没有好的升级方式。

解决方案

如果要想做到不重启升级,必须打破之前提到限制条件,booking.com 提供了一种方案,就是打破限制1,创造出一种特殊的模式,使实例处于GTID模式下仍然可以和非GTID的实例进行复制。 详细的方案介绍在这里 MySQL 5.6 GTIDs: Evaluation and Online Migration,代码的改动很小,就是让 sql/rpl_slave.cc 中的下面这段检查代码无效:



之前的升级方式是 A->B 这种拓扑,现在变为 A->C->B

实例A
5.5 版本的,目前业务用的数据库
实例C
5.6 版本的,一种中间状态实例,既可以和非GTID通信,又可以和GTID通信
实例B
5.6 版本的,数据迁移的目标

迁移步骤如下:

  1. 用热备份工具如 Percona XtraBackup 将 A 数据备份然后导入到B
  2. 建立 A->C->B 这种复制关系,其中 A->C 之间是文件位置协议,C->B 之间是 GTID 协议
  3. B、C和A同步的差不多的时候,在 A 上设 read_only,等B同步完成
  4. 将业务的数据操作指向B
  5. B 开始提供服务,迁移完毕

这里为了和之前迁移目标一致,多用了一个实例C,其实这时候可以把B给去掉,还是2个实例。可以看到,引入了C后,升级过程中并没有实例重启过程,只有一个短暂的只读时间段,这个是无法避免的,即使不用GTID,也会有这个过程。

目前RDS实例升级到5.6也是用这种方式。如果是集群到集群的话,要注意一点,处于中间状态的实例C最好只有一个,因为这种实例相当于一个GTID转换器,将A中没有 GTID 的 binlog 转成包含 GTID 的 binlog,然后传给B,如果有多个实例C的话,A中同一个binlog 中的事务会转换出不同的GTID,这与 GTID 和事务一一对应的根本原则相矛盾,复制会出问题。当然,如果能保证经过不同的C的binlog事务不会重复的话就可以有多个C。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL 基于 GTID 的组复制(MGR)
MySQL 基于 GTID 的组复制(MGR)
0 0
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
0 0
一个不规范操作导致MySQL主从同步中断(GTID模式)
一个不规范操作导致MySQL主从同步中断(GTID模式)
0 0
基于GTID搭建主从MySQL
想让主从之间使用gtid的方式同步数据,需要我们在配置文件中开启mysql对gtid相关的配置信息 找到my.cnf ,在mysqld模块中加入如下的配置。(主库从库都这样)
0 0
MySQL一主多从复制(基于GTID)
宿主机环境下,运行多个MySQL,实现数据的主从复制
0 0
剖析MySQL GTID复制
今儿的这篇博文,可以让大家快速了解GTID特性,并能灵活地运用到生产环境中,希望对大家有帮助。GTID原理介绍GTID又叫全局事务ID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局唯一的编号。
715 0
MySQL运维实战 之 价值一个亿的GTID监控
一、背景 现在的MySQL可谓是拿着望远镜也找不到对手,其中有一个非常大的特性就是GTID GTID的原理这篇文章不再展开,有兴趣的同学可以关注之前的GTID原理,GTID实战,GTID运维实战文章。
2143 0
MySQL启用GTID的限制
开启 GTID 之后,会由部分的限制,内容如下: 更新非事务引擎表GTID 同步复制是基于事务的,所以 MyISAM 存储引擎不支持,这可能导致多个 GTID 分配给同一个事务。 使用GTID时,使用非事务性存储引擎(如MyISAM)对表的更新不能在与使用事务性存储引擎(如InnoDB)的表的更新相同的语句或事务中进行。
1305 0
+关注
db匠
rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/
文章
问答
来源圈子
更多
让用户数据永远在线,让数据无缝的自由流动
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
让 MySQL 原生分布式触手可及
立即下载
好的 MySQL 兼容可以做到什么程度
立即下载
云数据库RDS MySQL从入门到高阶
立即下载