背景
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"字样,则返回严重错误,终止备份恢复流程。

发表评论

电子邮件地址不会被公开。 必填项已用*标注