以前我们遇到metadata lock的问题, 当时是因为业务逻辑导致了。 现在的场景是在线修改ddl语句,确切来说就是alter修改表结构 。 我们知道直接alter修改表结构,肯定会进行锁表,业务很瘦影响的。如果想避免锁表,可以采用pt-online-schema-change的方式。

关于在线修改表结构,原文链接  http://xiaorui.cc/?p=2144

介绍pt-online-schema-change:

那pt-online-schema-change又是什么原理,这里做些直接alter跟pt-online-schema-change的对比。 

一.直接执行 alter table XXX  ……
1.按照原始表(original_table)的表结构和DDL语句,新建一张不可见的临时表。
2.在原表上加write lock,此时对原表的所有U D I DDL 都是阻塞的。
3.执行insert into tmp_table select * from oldtable;
4.rename oldtable 和 tmp_table,再drop oldtable。
5.释放 write lock。
二.pt-online-schema-change

1.如果存在外键,根据alter-foreign-keys-method参数的值,检测外键相关的表,做相应设置的处理。

2.创建一个和你要执行 alter 操作的表一样的新的空表结构(是alter之前的结构)。

3.在新表执行alter table 语句,

4.在原表中创建触发器(3个)三个触发器分别对应insert,update,delete操作

5.从原表拷贝数据到临时表,拷贝过程中通过原表上的触发器在原表进行的写操作都会更新到新建的临时表。

6.Rename 原表到old表中,在把临时表Rename为原表,默认最后将原表删除,将原表上所创建的触发器删除。

限制:

1.该工具所适用的表必须是单一列的主键或者单一唯一键。

2.有外键参照的表要修改则不成功,需要指定参数–alter-foreign-keys-method=auto|rebuild_constraints|drop_swap|none

3.要修改的表上不能有trigger,否则修改失败。 


确实被第三条给坑过 ! 第三条的意思是说在原表上不能有触发器,但是有可能你的pt-online-schema-change被干掉,工具没有来得及删除触发器。 当你再去执行的时候,会提示你的原表已经存在trigger。

怎么解决?  直接删掉触发器和未完成的临时表。 pt-online-schema-change 貌似不支持任务暂停继续,只能重新来了。  

另外还有就是pt-online默认是有系统过载保护的,我想大家虽然都想要过载保护,但更想要稳定,别好不容易alter了一般,结果自己退出了。  解决的方法,在mysql里把连接数加大,然后pt-online-schema-change的启动参数里加上  –critical-load Threads_running=500 ,意思是说,可以承受500个链接, pt-online-schema-change在500 *1.2的时候,才提示报错。 

咱们看看触发器的样子,很明显看到他的REPLACE INTO导数据的语句。 

理解了在线改表结构的原理,那么我们开始操作alter。 

alter修改表结构是个危险的操作,大家要经常看看应用状况,可以通过show processlist; 我们可以看到有没有锁,如果有锁,那么就kill掉有可能造成锁的连接。Metadata lock是个常见的问题,由于我们的场景是数据分析,所以可以直接kill。  

这时候,我们查看应用的日志,还是看到了不少的错误。 Deadlock found when trying to get lock; try restarting transaction 。   我的开发环境是python,在官方文档及wiki’上查找些有用的信息,问题确定在 mysqldb autocommit身上。 你需要做的是,conn.autocommit(True) 。  虽然错误日志看似比以前少了不少, 但还会有异常。 结果随着把跟mysql有互动的计算节点从60个降到10个后,异常现象明显好了不少。 但异常就是异常,不能因为偶尔的异常就忽视不管。 

我觉得在不影响业务的情况下,有这么几种解决方法。 

1.   直接给用户说,你系统正在调整 !  现在支付宝,淘宝每个月也有那么一次调整上线,跟大姨妈似的! 

2.   当然很多时候,我们不能把对外的接口都关闭,这样太不友好。  可以采用把数据临时堆放到kafka或者redis里面。等表结构修改完毕,再开启消费程序。 

3.   对于一些异常的问题,可以使用事务的方法,避免插入脏数据。 

我问过sina的dba,问他们在高并发下如何处理表结构修改的问题。 他们很是粗暴 ! 看是否涉及到钱?  不涉及,那好上面的方法就够用了。 需要注意的是,pt-online的alter操作,会让dml语句变成串行。在线表结构修改时,尽量减少并发连接才是真理。 任务场景到了高并发,做一些大改动都时候不好把控的。 

总结:

    一切看场景,这次改表结构确实有些凶险 !  过度的信赖pecona pt-online-schema-change在线修改表结构工具,结果造成半夜锁表,而且是死锁。 大家分析锁的时候可以利用下面的语句进行分析。 


我再来说说pt-online-schema-change的性能问题,   他本身资源消耗不大,压力都在于mysql上。他的alter table和导表过程是非常的消耗磁盘io的,所以如果你的服务器不适ssd固态硬盘的话,肯有可能就磁盘傻逼了。 mysql单表300G的数据,5亿条数据,用了将近6个小时才搞完。在小范围业务的影响下,还算可以承受。




对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!
暂无相关产品

发表评论