buaacss

如果不用阿里云的 dms 之类的东西，可以用 gh-ost 。监听 binlog ，开始复制表，apply binlog, lock + rename table 。一切都是无感的非常好用。

分享一下之前写做的关于 gh-ost 的笔记。

对于数据库运维人员来说,MySQL 的大表表结构变更一直都是个麻烦事,为了尽量不影响业务,业内常用的解决方案无外乎三种，

一是利用 Percona 的 pt-online-schema-change,Facebook 的 OSC 等三方工具；

二是在备库修改通过切换实现滚动变更；

三则是升级 MySQL 到 5.6/5.7 通过官方 Online DDL 实现部分变更。

然而,引入触发器带来的锁竞争问题,主备切换带来的附加成本以及 Online DDL 的局限性都不让 DBA 省心。

gh-ost 的设计号称无触发器，可监控，可动态调整暂停等，更重要的是切换方案的优秀设计。下面就介绍下其实现原理和 cut-over(新旧表切换)的详细过程。

原理
gh-ost 不依赖于触发器,是因为他是通过模拟从库,在 row binlog 中获取增量变更,再异步应用到 ghost 表的。

有三种功能模式：

a.连接从库间接应用到主库/c 在从库上进行修改

连接从库
校验完后,在主库创建新表
迁移原表数据到新表
模拟从库的从库，拉取解析增量 binlog 应用到主库
cut-over 阶段，用新表替换掉原表

b.连接主库直接修改

直连主库
主库上创建 ghost 表
新表(ghost 表)上直接 alter 修改表结构
迁移原表数据到新表
拉取解析 binlog 事件,应用到新表
cut-over 阶段,用新表替换掉原表

两者不同的点就在于,通过连接从库来进行变更,对主库的性能影响最小

变更流程
以直连主库修改为例，详细介绍 gh-ost 做了哪些操作：

校验
测试 db 是否可连通,并且验证 database 是否存在
确认连接实例是否正确
权限验证 show / gh-ost / grants for current_user()
binlog 验证,包括 row 格式验证和修改 binlog 格式后的重启 replicate
原表存储引擎,外键,触发器检查,行数预估等

初始化
初始化 stream 的连接,添加 binlog 的监听
初始化 applier 连接,创建 ghosttable 和 changelogtable
判断是否符合迁移条件,写入结果到 tablesInPlace channel

迁移
迁移过程中,row copy 和 binlog apply 是同时进行,其中原则是 binlog apply 的优先级一定大于 row copy 操作的优先级。

状态展示
Copy: 9451000/10000060 94.5%; Applied: 31; Backlog: 0/100; Time: 8m26s(total), 8m26s(copy); streamer: mysql-bin.000040:68321839; ETA: 29s

cut-over
尝试 lock 原表
成功后,进行 rename 原子性操作,被 block 住
unlock 原表,rename 完成切换
后续中间表清理工作

迁移和切换的细节实现
关于 gh-ost 的实现，这里只挑了 rowcopy 和 binlog apply 的顺序问题和 rename 过程做了详细解析。

在数据迁移的过程中，数据变量有三个，暂且分为，A:来自原表的 rowcopy ，B:binlog 的 apply ，C:对原表的 dml 操作。

C 操作会记录 binglog 从而触发 B 操作，所以 B 操作一定在 C 操作的后面，因此一般情况下，会有 ACB ，CBA 两种组合，同时特殊情况如 binlog apply 延迟，则会有 CAB 这种组合。

分析三种组合之前要先了解 gh-ost 在 sql 改写方面是如何映射的：

RowCopy select insert ignore into 复制数据
BinlogApply insert replace into 复制期间增加数据

update update 复制期间变更数据

delete delete 复制期间删除数据

在上述原则的基础上，我们再来逐个分析不同顺序组合的影响:

insert 操作
binlog 是最权威的,gh-ost 的原则是以 binlog 优先。

假设一段数据正在复制到新表时产生了插入，我们来分情况看一下如何保证数据一致

复制需要先从原表 select 再插入到新表，假设插入（ binlog ）发生在 select 之前

那么新表在数据到达之前会先从 binlog 插入将数据插入，复制的数据到达后，因为有主键的原因，所以 insert ignore into 会忽略这行数据

如果插入（ binlog ）发生在 select 之后

那么 binlog 在到达新表后会使用 replace into 覆盖之前复制过来的数据

无论是先还是后都可以保证以 binlog 为准

update/delete 操作
一般情况下：

ACB 组合，即对已经 rowcopy 过的数据，出现对原表的 update/delete 操作。这时候会全部通过 binlog apply 执行，注意 binlog apply 的 update 是对某一条记录的全部列覆盖更新，所以不会有累加的问题。

CBA 组合，即对尚未迁移的数据，出现对原表的 update/delete 操作。这时候对新表的 binlog apply 会是空操作，具体数据由 rowcopy 迁移。

特殊情况下:

CAB 组合，即先对原表更新完以后，rowcopy 在 binlog apply 之前把数据迁移了过去，而在 binlog event 过来以后，会再次应用。这里看似有问题，但是结合 gh-ost 的 binlog aplly 的 sql 映射规则，insert 操作会被 replace 重新替换掉，update 会更新对应记录全部行，delete 会是空操作。最终数据还是一致的状态。

cut-over 过程
在 pt-osc 或者 online ddl 中,最后的 rename 操作一般是耗时比较短,但如果表结构变更过程中,有大查询进来,那么在 rename 操作的时候,会触发 MDL 锁的等待,如果在高峰期,这就是个严重的问题。所以 gh-ost 是怎么做的呢？

gh-ost 利用了 MySQL 的一个特性，就是原子性的 rename 请求，在所有被 blocked 的请求中，优先级永远是最高的。gh-ost 基于此设计了该方案：一个连接对原表加锁，另启一个连接尝试 rename 操作，此时会被阻塞住，当释放 lock 的时候，rename 会首先被执行，其他被阻塞的请求会继续应用到新表。

migrator.go:iterateChunks() 函数来确定何时开始 cut － over

具体切换流程如下
会话 A START

CREATE table tbl_old
防止 rename 过早执行

LOCK TABLES tbl WRITE, tbl_old WRITE
通过 lock_wait_timeout 设置为 2s 控制超时，超时失败会重试次数为配置 default-retries ，默认 60 次

新的请求进来，关于原表的请求被 blocked
RENAME TABLE tbl TO tbl_old, ghost TO tbl , 同样被 blocked

新的请求进来，关于原表的请求被 blocked
检查是否有 blocked 的 RENAME 请求，通过 show processlist
DROP TABLE tbl_old
UNLOCK TABLES
END

不同阶段失败后如何处理
如果第一步失败，退出程序
如果会话 A 建表成功，加锁失败，退出程序，未加锁
rename 请求来的时候，会话 A 死掉，lock 会自动释放，同时因为 tbl_old 的存在 rename 也会失败，所有请求恢复正常
rename 被 blocked 的时候，会话 A 死掉，lock 会自动释放，同样因为 tbl_old 的存在，rename 会失败，所有请求恢复正常
rename 死掉，gh-ost 会捕获不到 rename ，会话 A 继续运行，释放 lock ，所有请求恢复正常