gh-ost的表切换流程

2020-03-25  本文已影响0人  a50426d44eac

原文 Describing safe, blocking, atomic, pure-mysql cut-over phase

作者:shlomi-noach 26 Jun 2016

我们提供的方式是基于两个数据库连接的。假如我们的连接是C10,C20。应用的连接是C1..C9,C11..C19,C21..C29。

一些解释:

假如上面的过程当中C10或者C20失败了,会发生什么呢

先说结论,就算失败了,不会发生灾难性的事情,也不需要回滚。

不管发生什么事情,在操作的最后我们都会检查ghost表是否还存在。假如不在了,那就说明操作成功了。整个流程可以被看成是原子性的。

顺便说一下,如果操作失败了,可能会存在table_old表需要我们手动删除。其实删不删除都无所谓。如果你看不惯可以删除掉,不删除掉的话,也没关系,下一次操作就不用重建了。

对应用的影响

在流程开始之后到流程结束的时间里,不管是成功还是失败,应用的连接都会被阻塞住。成功的话,阻塞的语句会被执行到新表,失败的话,阻塞的语句会执行到旧表。

对复制的影响

复制只会看到RENAME操作,binlog是不会记录lock语句的。所以复制看到的是原子性的两表交换,不会有表不存在的情况。

针对网友的一些提问

为啥要用两个连接进行这么麻烦的流程?

因为一个连接在获取tbl的锁的情况下,无法进行rename操作(至少现在不能)。但是作者说他会说服工程师在MYSQL的下个版本当中实现,就不需要这么麻烦的操作了。(下面代码测试是我测试的,不是作者的)

admin@localhost [test] 11:39:32>lock table t write;
Query OK, 0 rows affected (0.00 sec)

admin@localhost [test] 11:39:36>rename table t to t10;
ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction
admin@localhost [test] 11:39:48>select @@version;
+---------------+
| @@version     |
+---------------+
| 5.7.22-22-log |
+---------------+
1 row in set (0.00 sec)

为啥要锁原来的表和创建的tbl_old表?

由于异步的应用binlog的日志,如果不锁住原表的话,可能会存在一些语句未被应用。为啥要锁住tbl_old表呢,作者自己也不太记得了,因为时间的原因,毕竟是回忆三年前的事情了,不过肯定是有原因的。

上一篇 下一篇

猜你喜欢

热点阅读