flush tables with read lock的一个潜在问题

长平狐 发布于 2012/11/01 11:57
阅读 912
收藏 0

看了mysqlperformance的一篇关于flush tables with read lock的文章,里面提到了它可能引发一些问题。好了,现学现卖,分享给大家。


现在很多的mysql备份工具在实现原理上都利用到了flush tables with read lock。这是为备份myisam表而设计的。像xtrabackup备份innodb表时并不会锁表,因为它也会备份在备份过程中新发生的事务日志,而对于myisam表的备份则是通过发出命令flush tables with read lock,然后拷贝myisam的相关表文件。那么在实际备份过程中可能会出现什么问题呢?答案是:有可能导致备份的时间严重的增长。下面来说说为什么会这样。


flush tables with read lock,也就是将所有的脏页都要刷新到磁盘,然后对所有的表加上了读锁,于是这时候直接拷贝数据文件也就是安全的。但是如果你发出命令flush tables with read lock时,还有其他的操作,而起是很耗时的操作呢?先说写操作,这个FTWRL肯定是得等的,等写操作完成才能执行FTWRL,这个很好理解。那么对于其他的读操作呢?比如说在FLWRL发出之前有一个query:select count(*) from tb,那么FTWRL也得等待(show processlist可以看到 waiting for table flush)。你可能会说在mysql中读与读不是不会排斥的吗,为什么需要等待呢?因为FTWRL是要flush脏页的,只有这样才真的能保证数据一致性(比如说在xtrabackup备份myisam表的时候),而在select count(*) from tb执行的时候,因为所有的操作都是在内存中操作,所以此时还不能完全flush,因此FTWRL就得等待。或许你还会有疑问,select的页不是脏页,为什么FTWRL还要等待呢?难道mysql不能做得更完善点吗?我觉得mysql还不是不会做的这么简单吧,等待的原因是因为这个表很大,无法一次性将所有的页都读到内存中来,而query具有原子性,总不可能执行一般被堵塞吧,所以说还是得乖乖的让它执行然,所以FTWRL就得等待了。


 所以在利用xtrabackup、ibbackup这种备份工具的时候,也要考虑到这点,在另一篇文章里面提到了由于DDL语句对备份造成的影响。

 


原文链接:http://blog.csdn.net/zbszhangbosen/article/details/7434173
加载中
返回顶部
顶部