今天发生一个故障，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
- sets the global read lock
- closes open tables
- sets a flag to block commits
3.SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
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; （执行成功） |
- DML操作在备份期间是不会被block(time 8)
- DDL操作在备份进程未获取某个table的meta data lock时，并发的DDL语句是可以执行的（time 9）
- DDL是不遵循MVCC的，session2执行DDL后，session1受到影响，一致性被破坏（time 10）
- Select tmp2获取table tmp2的table meta data lock，导致session2无法执行DDL，保证一致性（time 13）
- Mysqldump备份过程逐一获取table meta data lock,但是不是逐一释放，而是等到备份结束时统一释放 （time 16）
测试(5.1.48)：
由于5.1中没有引入meta data lock，所有在mysqldump备份过程中，并发session都可以执行DDL，导致备份集不一致，最终表现是使用此备份集恢复的备库在relay主库binlog会出现slave error，如DML找不到表，DDL重复操作等问题，之前一直以为是备份中断导致备份集不完整，现在终于找到原因了
思考：
虽然5.5中引入了meta data lock，但是仍然无法完全解决并发DDL对备份的影响：
- 5.1中由于没有引入meta data lock，在备份整个过程中并发DDL都会对其产生影响
- 5.5中引入meta data lock后，只是保证针对已经备份表的DDL会被block，只是降低了并发DDL影响的概率，解决方式是在start transaction与unlock tables之间获取实例上全部表的meta data lock，但是当表数量很大时，这个操作可以很耗时，而这个过程由于处于FLUSH TABLES WITH READ LOCK下，所以DML会被block，也许是因为DML执行频率远大于DDL操作，所以mysqldump选择了最大DML并发度