衡铁刚 1)2011-2013:Alibaba MySQL DBA 2)2014-至今: Alibaba 数据库PD
分类: Mysql/postgreSQL
2012-11-07 16:32:09
今天发生一个故障,MM复制结构(主备库),备库slave delay越来越大,造成在备库上的读与主库数据不一致,登上备库分析:
1.show processlist
drop table tmp_table 在 Waiting for table metadata lock
2.ps
mysqldump 在备份整个实例数据
kill了备份进程,drop table tmp_table执行成功,slave delay逐步减少
疑问:
1.metadata lock是什么东西
2.mysqldump中什么操作hold table metadata lock,hold范围是单表还是实例上全部表
mysqldump原理:
1.FLUSH TABLES
2.FLUSH TABLES WITH READ LOCK
4.start transaction
5.记录log pos
6.unlock tables
7.select * from ...
8.commit
测试(5.5.18):
Time |
sessionA |
sessionB |
1 |
Set auto_commit=0; |
Set auto_commit=0; |
2 |
create table tmp1(a int); |
|
3 |
create table tmp2(a int); |
|
4 |
create table tmp3(a int); |
|
5 |
FLUSH TABLES WITH READ LOCK; |
|
6 |
start transaction; |
|
7 |
unlock tables; |
|
8 |
|
insert into tmp1 value(1); (执行成功) |
9 |
|
drop table tmp1;(执行成功) |
10 |
Select * from tmp1;(表不存在) |
|
11 |
Select * from tmp2; |
|
12 |
|
insert into tmp2 value(1); (执行成功) |
13 |
|
drop table tmp2; (Waiting for table metadata lock) |
14 |
|
Kill drop table tmp2; |
15 |
Select * from tmp3; |
|
16 |
|
drop table tmp2; (Waiting for table metadata lock) |
17 |
commit; |
|
18 |
|
drop table tmp2; (执行成功) |
测试(5.1.48):
由于5.1中没有引入meta data lock,所有在mysqldump备份过程中,并发session都可以执行DDL,导致备份集不一致,最终表现是使用此备份集恢复的备库在relay主库binlog会出现slave error,如DML找不到表,DDL重复操作等问题,之前一直以为是备份中断导致备份集不完整,现在终于找到原因了
思考:
虽然5.5中引入了meta data lock,但是仍然无法完全解决并发DDL对备份的影响: