mysql ddl dml 导出_从库mysqldump过程中主库做DDL会怎样？

//从库mysqldump过程中主库做DDL会怎样？//

    今天时间有点晚了，就写一个小的知识点吧，在我们线上的环境中，大多都是采用的主从复制的架构，当我们在从库使用mysqldump进行逻辑备份的时候，如果此时主库有一个小的DDL操作，那么我们在从库上会看到什么现象？

     开始分析之前，我们先了解下mysqldump这个工具，我们知道，mysqldump是官方自带的逻辑备份工具，可以将数据表中的记录备份成一个可执行的sql文件。我们在使用的过程中，都会带上--single-transaction这个参数，这个参数有这么几个功能：

1、在导出数据之前，开启一个事务，拿到一致性视图。而由于MySQL中支持MVCC多版本控制协议，可以确保你在导出数据的过程中，其他DML语句是可以正常更新进表中的。

2、该参数避免了复制过程中的锁全表操作。

   但是我们需要知道，--single-transaction只支持有事务功能的存储引擎。如果是MyISAM这种不支持事务的存储引擎，那么在备份的时候只能锁全表。

   下面我们回答题目中的问题，如果我们在从库进行mysqldump备份操作，实际上从库上会进行这么几个步骤，这里我们画一个mysqldump的备份步骤：

步骤1 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
步骤2 START TRANSACTION  WITH CONSISTENT SNAPSHOT；
/* other tables */
步骤3:SAVEPOINT sp;
/* 时刻 1 */
步骤4:show create table `table_1`;
/* 时刻 2 */
步骤5:SELECT * FROM `table_1`;
/* 时刻 3 */
步骤6:ROLLBACK TO SAVEPOINT sp;
/* 时刻 4 */
/* other tables */

步骤1：设置RR隔离级别

步骤2：开启事务，拿到一致性视图

步骤3：设置一个保存点

步骤4：拿到table_1的表结构

步骤5：拿到table_1的表数据

步骤6：回滚到保存点

步骤7：拿到table2的表结构...

步骤8：......

    这里，假设我们主库上对table_1进行了DDL变更，新增了一个字段，那么从库可能会发生下面的情况：

1、如果主库上的DDL操作在步骤4之前到达从库，那么对mysqldump无影响

2、如果在时刻2到达，此时mysqldump会停止，并且会报错：Table definition has changed, please retry transaction

3、如果在时刻2和时刻3之间到达(也就是步骤5执行期间到达)，此时正在进行select * from table_1操作，mysqldump占用着表table_1的元数据锁，也就是MDL锁，binlog会被阻塞，发生主从延迟

4、如果在步骤6之后开始，则MySQL已经释放了table_1的元数据锁，那么不会对从库产生影响，mysqldump拿到的是DDL变更前的表结构。

有帮助的话还希望点下再看哈