昨天一同学说在slave上出现Waiting for table metadata lock&＃xff0c;metadata lock在5.5版本新加的(http://dev.mysql.com/doc/refman/5.5/en/metadata-locking.html)。metadata lock出现最多情况是一个事务中在t表进行DML时&＃xff0c;另外一事务想对t表DDL&＃xff0c;这时对t表DDL的事务只能等待&＃xff0c;就会出现metadata&＃xff0c;就是为了保护表的metadata。
出问题的备库上在跑mysqldump备份数据(参数有–single-transaction)&＃xff0c;一同学在主库drop table操作&＃xff0c;导致备库一直hang住(备库延迟)&＃xff0c;show processlist就可以看到metadata lock。为什么mysqldump会对表加metadata lock的&＃xff1f;
Mysqldump代码(5.5版本&＃xff0c;5.1版本有点区别)
1、 if->flush tables成功&＃xff0c;do->flush tables with read lock
2、 start transaction
3、 unlock tables
4、 backup(一个表一个表加metadata lock)
模拟mysqldump过程:
root&＃64;test >show TABLES;
&＃43;----------------&＃43;
| Tables_in_test |
&＃43;----------------&＃43;
| a |
| b |
| c |
&＃43;----------------&＃43;
Session 1:
root&＃64;test 06:46:20>flush TABLES WITH READ LOCK;
Query OK, 0 ROWS affected (0.00 sec)root&＃64;test 06:48:16>start TRANSACTION;
Query OK, 0 ROWS affected (0.00 sec)root&＃64;test 06:48:23>unlock TABLES;
Query OK, 0 ROWS affected (0.00 sec)root&＃64;test 06:48:38>select * FROM a;
Empty SET (0.00 sec)
Session 2:
root&＃64;test 06:45:25>drop TABLE a; hang …
session 3:
root&＃64;test 06:50:18>drop TABLE b;
Query OK, 0 ROWS affected (0.62 sec)
Session 1:
root&＃64;test 06:48:47>select * FROM b;
ERROR 1146 (42S02): TABLE &＃39;test.b&＃39; doesn&＃39;t exist
root&＃64;test 06:51:41>select * from c;
Empty set (0.00 sec)
Session 3:
root&＃64;test 06:51:03>drop TABLE c; hang…
从上面测试可以知道&＃xff0c;mysqldump是备份到哪个表&＃xff0c;锁到哪个表。这里有产生一个新的问题:
Session I:
Mysqldump未备份到b表
Session II:
写操作记录到binlog中
drop table b&＃xff0c;实际在mysqldump备份集里是没有b表的
当恢复时&＃xff0c;因为要apply 写b表的binlog&＃xff0c;但备份集恢复后根本就没有b表&＃xff0c;所以会报表找不到表&＃xff0c;这个在我们线上环境已出现。
总结&＃xff1a;因为5.1没有metadata lock&＃xff0c;所以出现几率会更大&＃xff0c;5.5已改进扫到哪里加锁到哪里。
转自&＃xff1a;http://www.dbunix.com/?p&＃61;3217
京公网安备 11010802041100号