Question

谁遇到过这样的锁的问题？

一个月前，给公司的两台linux机器配置了主从同步。当时配置主从同步的时候，为了建快照，使用过一条flush tables with read lock语句。后来使用unlock tables解锁了。 两周前，开发人员反映，表被人锁了。我在master的机器上show processlist，发现进程里竟然有一行，用户名是我自己的帐户，命令是flush tables with read lock。我觉得非常奇怪，我最近一周从来没有执行过flush tables with read lock这个命令，怎么会出现这样的进程呢？ 然后我尝试用自己的帐户解锁，执行unlock tables，执行完后flush tables with read lock这个进程还在，表还是被锁。无奈，只好使用mysqladmin kill id把此线程给杀了。后来这样的问题，一周前又出现了一次。 我们数据库的表全部使用Innodb存储引擎。所以平时备份使用的是以下的命令：mysqldump -u username --password=password --single-transaction --master-data --add-drop-table database-name | gzip > /backups/$backupfile执行这条语句，执行的是在线的、无阻塞的备份，不会锁表。 那么到底是怎么回事呢？实在是想不明白。。。有谁碰到过类似的问题吗？交流一下吧。非常感谢！

Answer 1

2# 昨天晚上又发生了类似的情况。。。看了日志，显示如下：mysqldump: Couldn't execute 'FLUSH TABLES WITH READ LOCK': MySQL server has gone away (2006)现在好像明白了，因为mysql server被中断了，所以定时备份的mysqldump无法执行FLUSH TABLES WITH READ LOCK这条语句，所以进程一激发就死在那里了，占用了大量的资源。总结： mysqldump程序竟然会激发FLUSH TABLES WITH READ LOCK？！ 但貌似只是锁很短的时间，然后自行解锁。（参考很多资料，说mysqldump的在线备份不会锁表的阿！）如果在这个时间里，mysql server出问题了，那么flush tables with read lock进程就僵死在那里了，然后就出现了应用界面无法访问数据库的情况。不过还是很疑惑哦，以后继续关注这个问题吧。。。hehe