gh-ost的cut-over过程

gh-ost的cut-over过程作者:魏新平,知数堂第5期MySQL实战班学员,第10期MySQL优化班学员,现任职助教。 Describing safe, blocking, atomic, pure-mysql cut-ove…

gh-ost的cut-over过程

作者:魏新平,知数堂第5期MySQL实战班学员,第10期MySQL优化班学员,现任职助教。

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

原文链接:https://github.com/github/gh-ost/issues/82

作者:shlomi-noach

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

  • C1..C9在 tbl 上进行正常的dml操作:INSERT, UPDATE, DELETE

  • C10: CREATE TABLE tbl_old (id int primary key) COMMENT=”magic-be-here”

  • C10: LOCK TABLES tbl WRITE, tbl_old WRITE

  • C11..C19,新进来的对tbl的操作,由于C10的锁,会被阻塞

  • C20: RENAME TABLE tbl TO tbl_old, ghost TO tbl

  • 由于C10加的锁,也会被阻塞住。但是当锁被释放后,会比C1..C9,C11..C19先执行。

  • C21..C29,新进来对tbl的dml操作还是会被阻塞住

  • C10: 检测C20的rename操作是否存在(在show processlist当中寻找rename关键字)

  • C10: DROP TABLE tbl_old

  • 大家还是被锁住,什么严重的事情都不会发生,除了删除这个tbl_old表。

  • C10:UNLOCK TABLES

  • BAM(象声词,不知道怎么翻译,尴尬,只能意会不能言传)!RENAME操作会先执行,ghost表会被重命名为tbl表,然后C1..C9,C11..C19,C21..C29会直接在新的tbl表上执行。

一些解释:

  • 创建tbl_old是为了阻止C20的RENAME操作

  • 当一个连接拥有对某个表的WRITE锁的时候,可以执行drop该表的操作。

  • 不管是谁先被阻塞,当一个表的INSERT/UPDATE/DELETE操作和RENAME操作同时被阻塞的情况下,RENAME操作总是会先执行。

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

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

  • 假如C10在CREATE tbl_old的时候发生错误,直接退出

  • 假如C10在LOCK tbl,tbl_old的语句发生错误,直接退出,表不会被锁住,app可以继续对tbl进行dml操作

  • 假如C10在C20刚要执行RENAME操作的时候连接直接挂了

  • WRITE锁会被释放掉,C1..C9,C11..C19可以继续在原表执行

  • C20会因为tbl_old表的存在而RENAME失败

  • 整个操作失败,但是没什么严重的问题产生,只是一些语句被阻塞了很短的一段时间。我们会重试整个cut-over流程。

  • 假如C10在C20被阻塞后挂了,发生的事情和上面的流程差不多。锁释放,C20失败(因为tbl_old的存在),其他所有的被阻塞的语句会正常在原来的表上执行

  • 假如C20在C10 DROP表之前挂了,我们会捕捉到错误并按计划执行。删除表并且释放锁。没什么严重的事情发生,顶多一些语句被阻塞一会。我们需要重新尝试整个流程。

  • 假如C20在C10 DROP后释放锁之前挂了,和上面发生的事情一样。

  • 假如C10和C20都挂了。锁被释放,RENAME失败,C1..C9,C11..C19,C21..C29阻塞的语句会正常在tbl上执行。

不管发生什么事情,在操作的最后我们都会检查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)

代码100分

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

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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/9246.html

(0)
上一篇 2023-02-12
下一篇 2023-02-12

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注