一回事故的想起

背景:MySQL5.6.40,库比较小,row+gtid复制环境,但由于原先种种原因,备份还原在从库后,开启复制存在大气1062,1032漏洞非常多,gtid卡在靠前岗位。做复制的时候没有其它从库,每小时的备份也被运转停了。

开头一贯没境遇过那种情状,相对测试环境正式环境相比复杂,而且猜想只怕是事先备份还原一贯没用过备份一致性参数导致,并且发现错误也从未手工业检查(那几个题材还在斟酌中,有相逢并领会原因的伙伴欢迎引导)。

为了未来幸免因为恢复生机不如时导致的数额丢失,特别总括本次故障进度和豪门谈论、分享。

简化时间轴如下图:

早先—->备份主库—->苏醒从库—->复制error1032,1062—->删除从库再度复苏—->复制error1032,1062—->reset
master从库、主库—->准备删除从库—->误操作删主库—–>恢复生机主库—–>跳过大量106贰 、1032荒谬—->找drop
db地方复苏从库—->相比较中央数据—->手工业补数据—->停止

上边遵照作者的记得描述下立即的场地:

壹 、第③回备份主库、搭建从库

率先次搭建从库,从主库的备份未利用master-data=2
single-transaction(保证工作备份时的一致性)参数迁移后,报大批量1062和1032错误(家家有本难念的经,不多说了)

 

图片 1

二 、第三次恢复主库到从库

于是乎第3遍重复导入。

一律报错。在导入从库前应用reset master;将从库binlog清除。

出于操作人士持续解reset master含义及实施结果,又在主库做了reset master;

结果导致主库全数binlog日志被免除并且binlog position置为1;

那里贴以下官方认证,别没事干就在主库上用那条。

 

图片 2

重新导入发现依然大批量报1032,1062谬误。

是因为猜疑是因为备份时没利用–single-transaction参数,准备删除从库,加参数重新备份主库。

③ 、误删除主库

结果误操作删除主库(这一个锅一片段原因要甩给mysql
naivcat那几个工具,垂直排列库,稍微不注意就便于点错。如故提议咱们听吴老师的用合法的workbench),删库如故四个人查对,在操作系统上实施,删前没把握最棒备份1次。

删库这种操作谨慎小心再登高履危,首要的事体说3次!

删库那种操作谨慎小心再小心,主要的业务说二回!

删库那种操作谨慎小心再严俊,重要的事体说3次!

drop database;(在naivcat上右键删除库,但binlog日志中还是会记录DROP
DATABASE这条记下)

那时为了保障工作不中断,立马在主库上经过以前的备份文件恢复生机了一套库,当然数据肯定丢失了,但能够推算丢失数据的时辰段(从备份实现起头—>DROP
DATABASE)。

PS.请不要问小编怎么删库,为何删完又恢复生机了一套库,因为都不是自个儿干的。。。。。。

侥幸的是误删除主库但一贯不删除从库,而且从库的io_thread仍旧处于yes状态(回看吴先生的科目,也正是说固然库被去除了但实在删库前的数目=备份数据+io_thread已下载的去除主库前的多少),由于sql_thread仍旧停到gtid靠前的职位

 

图片 3

肆 、跳过多量1032,1062错误

其最近候假使看下备份文件的gtid地点,并purge到该岗位(在此之前备份丢了,随便找了三个备份的截图,驾驭万岁)。

##那边说圣元下为啥一向purge到备份的末了地方,因为书库备份的数量中1032和1062错误太多,且主库已经去除不能通过脚本相比较跳过大量1032,1062荒唐(吴老老师和朋友情提供),在能够确认保障是从主库逻辑备份过来的情事下(主从数据一致),我们选择急速跳过多量张冠李戴(偷懒加意况急),直接purge到备份最终的职位。

 

图片 4

##上图是随便截的叁个备份文件最开首的职位,请忽略那多少个gtid的值,意思通晓就行。

set @@gtid_purged=’fb1f83af-1915-11e8-811b-000c29c4d77d:1-500′;

注:‘500’代表备份文件最终三个履行的工作的gtid。gtid_purged代表数据库已经在从库上重播过1-500那段工作。

5、找到主库DROP DATABASE的GTID地点

purge到该地方然后再鲜明drop
database的任务上(思路:借使不分明dropdatabase的职位就start slave
那么从库会应用主库的binlog也就会履行主库drop
database的操作,为了幸免从库重放主库drop
database的操作,我们要想方设法让gtid在从库停到drop
database前一个gtid的职分)

注:能够透过大约删库时间可能从从库的show slave
status\G上收看主库的binlog地点从后往前找DROP
DATABASE的任务,假设删库后做了reset
master那就只好从从库的relay-bin-log上找了(切记主库没事别reset
master);

mysqlbinlog    -vvv  –base64-output=decode-rows  relay-bin.000017

 

图片 5

⑥ 、运维从库SQL_THREAD

在从库上实行start slave sql_thread
until的指令,那里须求表明,因为主库已经过来,业务跑起来了,那时候开启io_thread没有怎么意思,所以只用让从库的sql_thread线程回放DROP
DATABASE在此之前的业务就行。

root@localhost[{none}]>start slave sql_thread until
sql_before_gtid=’fb1f83af-1915-11e8-811b-000c29c4d77d:2343′;

初阶slave,并且让从库gtid停在主库drop
database操作以前二个gtid就能够,再还原到主库就能即刻投入使用,还不会造成数据丢失。

 

图片 6

保障从库executed_gtid_set到了笔者们before的前二个值就足以备份了,然后dump那份数据恢复生机主库,当然如若从库质量不错的话能够设想应用端更改连接,那样速度更快一些。

但正如麻烦的就是,要保管生产的实时性,删库后立即在主库上还原了前头用来过来从库的备份文件,这就肯定会促成人中学间数据丢失。

柒 、数据比较还原

那时不得不利用用事先用于搭建从库的备份再回复二个库,再用pt-table-checksum相比主库和回复库,从库和回复库不平等的多少,用pt-table-sync生成对应语句。然后手工业把多少补进系统中。

对比1:主库:备份数据恢复生机的库—->指标:找到主库在删库之后接纳又写入了什么数据。

对比2:从库:备份数据复苏的库—->目的:找到备份数据之后,删库从前运用在主Curry写了怎么数据。

因为量不是相当大,手工业比较一下就行,当然数据复苏的坑也有无数,可是大多都被研究开发填了。

总结:

首轮遭逢删库情状照旧多少蒙,幸而主库用的是GTID找binlog日志中的地方相对简单一点。这一次苏醒最幸运的正是万幸从库卡在靠前的岗位,要不然就是有了从库,数据也会被删了,恢复起来绝对更麻烦些。

对此gtid的上升,课上吴炳锡先生都讲过,但是一上手依然慢了几拍,依然要经超过实际战多演习加深手感幸免在真实况形下懵逼。

最终尤其多谢:知数堂叶金荣先生和吴炳锡先生在故障产生时予以的助手和支撑。

转发请申明出处 https://www.cnblogs.com/Lemon-DBA/p/9396546.html

相关文章