gh-ost原理

gh-ost原理

一、三种模式架构图

1、连上从库，在主库上修改

这是gh-ost默认的工作模式，它会查看从库情况，找到集群的主库并且连接上去，对主库侵入最少，大体步骤是：

在主库上创建_xxx_gho、_xxx_ghc，并修改_xxx_gho表结构；
从slave上读取二进制日志事件，将变更应用到主库上的_xxx_gho表；
在主库上读源表的数据写入_xxx_gho表中:insert into igore....select；
在主库上完成表切换；

2、直接主库修改

在主库上创建_xxx_gho、_xxx_ghc，并修改_xxx_gho表结构；
从主库上读取二进制日志事件，将变更应用到主库上的_xxx_gho表；
在主库上读源表的数据写入_xxx_gho表中:insert into igore....select；
在主库上完成表切换；

3、在从库上修改和测试

这种模式会在从库上做修改。gh-ost仍然会连上主库，但所有操作都是在从库上做的，不会对主库产生任何影响。在操作过程中，gh-ost也会不时地暂停，以便从库的数据可以保持最新。
--migrate-on-replica选项让gh-ost直接在从库上修改表。最终的切换过程也是在从库正常复制的状态下完成的。
--test-on-replica表明操作只是为了测试目的。在进行最终的切换操作之前，复制会被停止。原始表和临时表会相互切换，再切换回来，最终相当于原始表没被动过。主从复制暂停的状态下，你可以检查和对比这两张表中的数据。

二、原理

1、检查校验环境

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

2、创建binlog streamer连接到主库或者从库，添加binlog的监听

3、创建log表_xxx_ghc和ghost表_xxx_gho并修改ghost表结构到最新

4、开始迁移数据：row copy和binlog apply同时进行

   1）最小值：select `id` from darren`.`t4` order by id` asc limit 1；
   2) 最大值：select `id` from darren`.`t4` order by id` desc limit 1；
   3) 计算第一个chunk： select `id` from `darren`.`t4` where `id` >= _binary'1' and `id` <= _binary'58594' order by `id` asc limit 1 offset 999
        最后一个chunk如果不足1000，那么上面sql查询为空，这时运行：
        select `id` from (
             select `id` from `darren`.`t4`
             where `id` > _binary'58000' and `id` <= _binary'58594' order by `id` asc limit 1000
        ) select_osc_chunk
        order by `id` desc limit 1；
   4）循环插入数据：insert ignore into `darren`.`_t4_gho` (`id`, `name`, `c1`)
                 (select `id`, `name`, `c1` from `darren`.`t4` force index (`PRIMARY`)
                  where `id` >= _binary'1' and `id` <= _binary'1000' lock in share mode
                 )

4.1、rowcopy数据和应用binlog顺序不同是否产生数据冲突

数据迁移过程中sql映射关系：

rowcopy和binlog应用各种排列组合：

数据迁移过程，涉及三个操作：A:对原表进行rowcopy；B:应用程序的DML;C:应用binlog到新表，因为DML操作才会记录binglog，所以C操作一定在B操作的后面,共有如下几种组合:

1.insert 操作

binlog是最权威的,gh-ost的原则是以binlog优先,所以无论任何顺序下,数据都是和binlog保持一致,如果rowcopy在后,会insert ignore,如果binlog apply在后会replace into掉。

2.update/delete 操作

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

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

特殊情况下:

先对原表更新完以后，rowcopy在binlog apply之前把数据迁移了过去，而在binlog event过来以后，会再次应用，这里有问题？其实结合gh-ost的binlog apply之前把数据迁移了过去，

而在binlog的sql映射规则,insert操作会被replace重新替换掉,update 会更新对应记录全部行,delete 会是空操作。最终数据还是一致的状态。

4.2、binlog同步数据何时结束？

 copy完数据向_xxx_ghc写入status:AllEventsUpToLockProcessed:1533533052229905040,当binlogsyncer过滤到该值表示所有event都已应用

5、copy完成后进行原子性cut-over阶段

5.1) C10:
                创建magic表_xxx_del，目的为了防止过快的进行rename操作和意外情况rename
                对源表和magic表_xxx_del加write锁
5.2) C11...C19: 新的请求进来，关于原表的请求被blocked
5.3) C20:       执行：rename table `t4` to `_t4_del`,`_t4_gho` to `t4`；这时被阻塞，timeout：3s。(这一步只有binlog event应用完成后)
5.4) 检查是否有blocked 的RENAME请求，通过show processlist
5.5) C10:
                删除magic表（只有show processlist里存在被block的rename才进行）
                释放琐

不同阶段失败后如何处理：

如果5.1失败，退出程序，比如建表成功，加锁失败，退出程序，未加锁
rename请求来的时候，会话C10死掉，lock会自动释放，同时因为_xxx_del的存在rename也会失败，所有请求恢复正常
rename被blocked的时候，会话C10死掉，lock会自动释放，同样因为_xxx_del的存在，rename会失败，所有请求恢复正常
C20死掉，gh-ost会捕获不到rename，会话C10继续运行，释放lock，所有请求恢复正常

6、清理战场

7.1） 关闭binlogsyncer连接
7.2） 删除源表和_t4_ghc表