相关阅读:
mysqldump与innobackupex备份过程你知多少(二)
想必大家都知道,mysqldump备份时可以使用--single-transaction + --master-data两个选项执行备份(老实讲,为图方便,本人之前很长一段时间,生产库也是使用mysqldudmp远程备份的),这样备份过程中既可以尽量不锁表,也可以获取到binlog pos位置,备份文件可以用于数据恢复,也可以用于搭建备库。看起来那么美好,然而,其实一不小心你就发现自己已经在坑里了。
1.3.1. 坑一
使用--single-transaction + --master-data时,myisam表持续不断插入,并用于搭建备库。
首先在A库上把myisam表的数据行数弄到100W以上
A库新开一个ssh会话2,使用如下脚本持续对表t_luoxiaobo2进行插入操作(该表为myisam表),限于篇幅,请到如下为知笔记链接获取:
http://5d096a11.wiz03.com/share/s/1t2mEh0a-kl_2c2NZ33kSiac1Rgvxq1vgkhL21ibWU2cLidk
A库新开一个ssh会话3,清空查询日志:
现在,A库在ssh会话3中,使用mysqldump备份整个实例
备份完成之后,A库在ssh会话2中,停止持续造数脚本
A库在ssh会话2中,查看备份文件中的binlog pos
A库在ssh会话3中,查看查询日志,可以发现在UNLOCK TABLES之后,select *…t_luoxiaobo2表之前,还有数据插入到该表中:
现在,我们将这个备份文件用于B库上搭建备库,并启动复制,可以发现有如下复制报错:
从上面的结果中可以看到,主键冲突了,也就是说备份的表t_luoxiaobo2中的数据与备份文件中获取的binlog pos点并不一致,咱们现在在B库中,查询一下这个表中大于等于这个冲突主键的数据,从下面的结果中可以看到,备份文件中如果严格按照一致性要求,备份文件中的数据必须和binlog pos点一致,但是现在,备份文件中的数据却比获取的binlog pos点多了5行数据:
现在,咱们去掉--single-transaction选项,重新执行本小节以上步骤,重新搭建从库,看看是否还有问题(这里限于篇幅,步骤省略,只贴出最后结果):
从上面的show slave status输出信息中我们可以看到,去掉了--single-transaction选项之后的备份,用于搭建备库就正常了。另外,我们重新在A库上查看查询日志也可以发现,只搜索到flush语句而没有搜索到unlock tables、set session transaction.. 、start transaction.. 语句,说明备份过程没有开启一致性快照事务,没有修改隔离级别,是全程加全局读锁的,mysqldump备份进程结束退出之后mysql server自动回收锁资源:
也许你会说,我们数据库环境很规范,没有myisam表,不会有这个问题,OK,赞一个。
1.3.2. 坑二
使用--single-transaction + --master-data时,innodb表执行online ddl,备份文件用于搭建备库(注意,本小节中的数据库实例与前一小节不同)。
这次我们操作Innodb表,在A库上先把t_luoxiaobo表的数据也弄到几百万行。
A库在ssh会话2中,使用如下脚本持续对表t_luoxiaobo进行DDL操作(该表为innodb表),限于篇幅,请到如下为知笔记链接获取:
http://5d096a11.wiz03.com/share/s/1t2mEh0a-kl_2c2NZ33kSiac0tjwkE3KHkhU2_9gwt3mTldI
A库在ssh会话3中,清空查询日志:
现在,A库在ssh会话3中,使用mysqldump备份整个实例:
A库在ssh会话2中,停止DDL添加脚本。
A库在ssh会话2中,查看备份文件中的binlog pos:
现在,我们将这个备份文件用于在B库中搭建备库,并启动复制,从下面的结果中可以看到,复制状态正常:
现在我们回到A库上,对表t_luoxiaobo插入一些测试数据:
在B库上查询复制状态和表t_luoxiaobo中的数据:
到这里,看起来一切正常,对不对?开心吗?先等等,请保持DBA一贯严谨的优良传统,咱们在主库上使用pt-table-checksum工具检查一下:
从上面的信息中可以看到,表luoxiaobo.t_luoxiaobo的检测DIFFS 列为16,代表主从有数据差异,神马情况?别急,咱们先来分别在AB库查询下这张表的数据行数,从下面的结果可以看到,该表主从数据差异2097152行!!!
发生什么了?也许你会说,平时使用mysqldump不都是这样的吗?没毛病啊。
为了证实这个问题,下面我们打开查询日志查看一下在start transaction with consistent snapshot语句和select … 之间是否有DDL语句,如下:
现在,我们打开备份文件,找到表t_luoxiaob的备份语句位置,可以看到并没有生成INSERT语句:
到这里,是不是突然心弦一紧呢? so……如果你决定继续使用mysqldump,那么以后搭建好备库之后,一定要记得校验一下主备数据一致性!!!
1.3.3. 有办法改善这这些问题吗?
在寻找解决办法之前,咱们先来看看mysqldump的备份选项--single-transaction和--master-data[=value]的作用和使用限制。
so……--single-transaction选项中明确说明了如果使用了该选项,那么在备份期间如果发生DDL,则可能导致备份数据一致性被破坏,select检索不到正确的内容。另外,该选项仅仅只适用于事务引擎表,不适用于非事务引擎。作为DBA,很多时候是非常无奈的,虽然有各种规范,但是保不齐就是有漏网之鱼,这个时候,生活还得继续,工作还得做好, 那么,有什么办法可以缓解这个问题吗?有的:
下一篇"mysqldump与innobackupex备份过程你知多少(四)"我们将接着介绍"innobackupex”,精彩内容不容错过,敬请期待!!