192.168.1.1-路由器设置 > 路由器设置 > 192.168.1.1打不开 >

mysqldump与innobackupex备份过程知多少(三

文章摘要

A库新开一个ssh会话2,利用如下脚本持续对表t_luoxiaobo2进行插入操作(该表为myisam表),限于篇幅,请点击此处获请看如下

 

  A库新开一个ssh会话2,利用如下脚本持续对表t_luoxiaobo2进行插入操作(该表为myisam表),限于篇幅,请点击此处获取。

  从的消息中能够看到,表luoxiaobo.t_luoxiaobo的检测DIFFS 列为16,代表主从无数据差别,神马环境?别急,我们先来别离在AB库查询下这张表的数据行数,从下面的成果能够看到,该表主从数据差别2097152行!!

  此选项将事务隔离模式设置为REPEATABLE READ,并在备份数据之前向server发送START TRANSACTION SQL语句以显示一个事务快照。仅合用于InnoDB如许的事务表,因为是在事务快照内进行备份,如许能够使得备份的数据与获取事务快照时的数据是分歧的,并且不会堵塞任何使用法式对server的拜候。

  两个选项施行备份(诚恳讲,为图便利,本人之前很长一段时间,出产库也是利用mysqldudmp近程备份的),如许备份过程中既能够尽量不锁表,也能够获取到binlog pos,备份文件能够用于数据恢复,也能够用于搭建备库。看起来那么夸姣,然而其实一不小心你就发觉踩到坑了

  此刻,我们将这个备份文件用于在B库中搭建备库,并启动复制,从下面的成果中能够看到,复制形态一般:

  在寻找处理法子之前,我们先来看看mysqldump的备份选项和--master-data[=value]的感化和利用。

  so,选项中明白申明了若是利用了该选项,那么在备份期间若是发生DDL,则可能导致备份数据分歧性被,select检索不到准确的内容。别的,该选项仅仅只合用于事务引擎表,不合用于非事务引擎。作为DBA,良多时候常无法的,虽然有各类规范,可是保不齐就是有丧家之犬,这个时候,糊口还得继续,工作还得做好, 那么,有什么法子能够缓解这个问题吗?有的:

  与--dump-slave选项雷同,若是选项值为2,则CHANGE MASTER TO语句将作为SQL正文写入备份文件,因而仅供参考;当备份文件被从头加载时,这个正文不起感化。若是选项值为1,则该语句不会正文,并在从头加载备份文件时会生效(被施行)。若是未指定选项值,则默认值为1。

  从的show slave status输出消息中我们能够看到,去掉了--single-transaction选项之后的备份,用于搭建备库就一般了。别的,我们从头在A库上查看查询日记也能够发觉,只搜刮到flush语句而没有搜刮到unlock tables、set session transaction.. 、start transaction.. 语句,申明备份过程没有分歧性快照事务,没有点窜隔离级别,是全程加全局读锁的,mysqldump备份历程竣事退出之后mysql server主动收受接管锁资本:

  A库在ssh会话2中,利用如下脚本持续对表t_luoxiaobo进行DDL操作(该表为InnoDB表),限于篇幅,请点击此处获取。

  留意:该选项仅合用于事务引擎表,对于MyISAM或MEMORY表因为不支撑事务,所以备份过程中这些引擎表的数据仍可能发生更改。

  到这里,若何做选择就看你有什么样的需求了,下一篇我们将谈一谈innobackupex的备份过程和道理。

  此刻,我们打开备份文件,找到表t_luoxiaob的备份语句,能够看到并没有生成INSERT语句:

  在进行单事务备份时,为确保无效的备份文件(准确的表内容和二进制日记),不克不及有其他毗连应利用语句:ALTER TABLE,CREATE TABLE,DROP TABLE,RENAME TABLE,TRUNCATE等DDL语句。这会导致分歧形态被,可能导致mysqldump施行SELECT检索表数据时查询到不准确的内容或备份失败 。

  到这里,看起来一切一般,对不合错误?高兴吗?先等等,请连结DBA一贯严谨的优秀保守,我们在主库上利用pt-table-checksum东西查抄一下:

  1) 就好像上文中演示步调中那样,去掉选项进行备份,此时零丁利用选项时会主动,备份过程中整个实例全程锁表,不会发生备份数据与获取的binlog pos点不分歧的问题,如许,用该备份来搭建备库时就不会呈现数据冲突。可是问题显而易见,备份期间数据库不成用,若是采用这种方式,至多需要在营业低峰期进行备份2) 利用innobackupex备份东西

  从的成果中能够看到,主键冲突了,也就是说备份的表t_luoxiaobo2中的数据与备份文件中获取的binlog pos点并不分歧,我们此刻在B库中,查询一下这个表中大于等于这个冲突主键的数据,从下面的成果中能够看到,备份文件中若是严酷按照分歧性要求,备份文件中的数据必需和binlog pos点分歧,可是此刻,备份文件中的数据却比获取的binlog pos点多了5行数据:

  到这里,是不是俄然心弦一紧呢?so..若是你决定继续利用mysqldump,那么当前搭建好备库之后,必然要记得校验一下主备数据分歧性!!

  利用此选项备份时会在备份文件中生成change master to语句,利用的binlog pos是利用的备份server本人的binlog pos,可利用备份文件用于将另一台办事器(恢复这个备份文件的办事器)设置为备份server的从库。

  利用时,InnoDB表施行online ddl,备份文件用于搭建备库(留意,本末节中的数据库实例与前一末节分歧)。

  --master-data选项主动封闭--lock-tables选项。同时还会打开--lock-all-tables,除非指定了选项,在指定了选项之后,只要在备份起头时间内才加全局读取锁。

  此刻,我们去掉--single-transaction选项,从头施行本末节以上步调,从头搭建从库,看看能否还有问题(这里限于篇幅,步调省略,只贴出最初成果):

分享到:

tags:192.168.2.1

最近更新-关于我们 - 联系我们 - 广告服务 - 友情链接 - 网站地图 - 版权声明
CopyRight2009-2011 All Rights Reserved 192.168.1.1 路由器设置jmqy.com