zoukankan      html  css  js  c++  java
  • Metadata Lock原理4

     http://blog.chinaunix.net/uid-28212952-id-3400571.html    Alibaba 

    今天发生一个故障,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并发度
    附上:mysqldump执行流程

     

  • 相关阅读:
    java中eclipse控制台接受输入的方法
    java中Timer类的详细介绍(详解)
    java中Timer类的详细介绍(详解)
    java中Timer类的详细介绍(详解)
    java中Timer类的详细介绍(详解)
    java中ReentrantLock类的详细介绍(详解)
    java中ReentrantLock类的详细介绍(详解)
    java中ReentrantLock类的详细介绍(详解)
    java中ReentrantLock类的详细介绍(详解)
    Spring中WebApplicationInitializer的理解
  • 原文地址:https://www.cnblogs.com/zengkefu/p/5673900.html
Copyright © 2011-2022 走看看