MySQL内核月报 2014.09-MySQL· 限制改进·GTID和升级-阿里云开发者社区

开发者社区> db匠> 正文

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 系统用户最大文件打开数限制
mysql 系统用户最大文件打开数限制 纸上得来终觉浅,绝知此事多宕机...记录一下自己很蠢的一次故障处理过程。   上周的时候,一个刚上线的系统又开始反映登不上了,因为最近这个系统也老是出现这个问题,开发也一直在找问题中,所以也没太在意。
976 0
结合AliOS Things谈嵌入式系统通用问题定位方法(2):内核相关基础
内核提供的任务创建接口,会存在参数指定当前任务创建完立即运行还是需要显示调用start运行,需要注意。如果在创建任务时指定了立即执行,而在创建任务后去设置任务参数,可能是不生效的。(尤其posix的pthread接口经常遇到这种问题)
78 0
+关注
db匠
rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/
497
文章
0
问答
来源圈子
更多
阿里云数据库:帮用户承担一切数据库风险,给您何止是安心!支持关系型数据库:MySQL、SQL Server、PostgreSQL、PPAS(完美兼容Oracle)、自研PB级数据存储的分布式数据库Petadata、自研金融级云数据库OceanBase支持NoSQL数据库:MongoDB、Redis、Memcache更有褚霸、丁奇、德哥、彭立勋、玄惭、叶翔等顶尖数据库专家服务。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载