一个mysqldump导出失败的案例分析

 背景

MySQL全量逻辑备份恢复最基础的方法，就是mysqldump生成文本，再通过source 命令直接导入。一般用于实例迁移或者版本升级。

这里说明最近碰到的一个失败例子。

描述

这个例子可以简要复现如下，在源库上执行如下操作:

use mydb;

create table t1 (id int);

create view v1 as select * from t1;

drop table t1;

 

之后执行 mysqldump mydb，发现mysqldump中途退出。简化后出错原因很明显，就是视图v1对应的表t1已经不存在，这个视图本身非法。

这个错误很危险，因为如果没有捕获这个错误，直接认为mysqldump执行完成，并将生成的结果应用于目标库，则会导致数据丢失！

其实这个问题并不像看起来那么简单。

一个问题

mysqldump只需要生成show create view v1的结果即可----这会导致在目标库source的时候报错----为什么会在dump的时候就报错？

MySQL Tips: mysqldump导出整库，默认情况下，会在导出前对整库里面的每个表加读锁，即Lock tables tb1 read, tb2 read,..., tbn read.

​本例中由于视图v1需要的实体表t1已经不存在，lock table v1 read 返回失败。因此整个库所有表都没有正常导出。如果以此输出结果导入到目标库，则整库数据丢失。

MySQL Tips: mysqldump若正常结束，生成的文件结果最后一行是“-- Dump completed on + 时间”。

​使用dump的结果文件必须先检查结果文件的完整性，判断末行的文本是一个推荐操作。

 

导整库的时候为什么需要对所有表都加读锁呢？目的是为了得到一致性读视图。也就是说，在导出整库期间，不会有更新，这样才保证导出数据的一致性。

 

而实际上这个是历史遗留问题，InnoDB本身支持一致性读，也就是说只要启动一个事务（begin/start transaction),则在此事务存续期间，对于本实例内InnoDB表的更新，此导出事务均不可见。也就是说InnoDB事务可以保证事务期间看到的视图与事务启动瞬间看到的一致。

 

而锁表会堵住更新，导库又往往是长时间的操作，因此备份期间能允许读写对OLTP应用来说至关重要。

MySQL Tips: 若确保mysqldump导出的数据中只有InnoDB表，可以用 --single-transaction 避免锁表。

问题继续

加了--single-transaction后不需要锁表，是否还会导致mysqldump失败？答案依然是会。这次我们发现输出的错误是 "SHOW FIELDS FROM v1" 失败。由于show fields v1需要解析视图并列出执行结果的列信息，而表t1已经不存在因此报错。

 

问题是，为什么需要执行一个 SHOW FIELDS?

 

这就说到restore的依赖问题。

 

MySQL Tips: mysqldump生成导出文件时。同一个库内实体表先生成，之后是视图。多个实体表是按照字母升序生成，多个视图也是按字母升序生成。

这样就可能存在这样的情况，某个视图v1依赖视图v2，而v1的字母排序前于v2。比如视图名为x，而依赖的另一个视图名为y。这样在按顺序输出的时候，如果不做任何处理，在输出文件中就会先出现create view x ...而由于x依赖于y但y还没有生成，就会导致restore阶段执行失败。

 

MySQL Tips: mysqldump解决视图依赖问题的方法，就是在生成实体表阶段，如果碰到视图，则创建一个同名的临时实体表，该表的结果与视图完全相同。

配合的策略是在生成真正的视图前，先将临时实体表删除。这样在restore阶段，创建任何视图V1前，它所依赖的视图V2有两种情况：

1) 字母排序V2 > V1，则当前库中有一个名为V2的临时实体表，这样视图V1能够正常创建;

2) 字母排序V2 < V1，则此时视图V2已经存在，这样视图V1能够正常创建;

 

以上策略解决了视图循环依赖的问题，这个机制需要早生成实体表阶段得到视图执行结果的列名，因此需要执行一个 SHOW FIELDS。

实践建议

上面的分析说明了"为什么”，以下操作型的读者希望的实践建议：

1) 为避免无效视图影响导出，可以在调用mysqldump时增加--force参数，强行忽略此错误。这个忽略不会对数据造成影响；

 

2) 使用--result-file参数保存mysqldump结果，同时将所有控制台收到的返回都作为报警返回给调用端；

 

3) 检查 result-file的最后一行，若无“Dump completed on"字样，则返回严重错误，终止备份恢复流程。