一遍事故的追思

发布时间:2019-10-30  栏目:NoSQL  评论:0 Comments

背景:MySQL5.6.40,库十分的小,row+gtid复制处境,但鉴于之前各样原因,备份还原在从库后,开启复制存在一大波1062,1032错误,gtid卡在靠前岗位。做复制的时候从不任何从库,每时辰的备份也被运转停了。

莱茵河沉船事故 回想前段时间全世界主要沉船事故

二〇一五-06-28 22:29:44
来源:中夏族民共和国历史轶事广告id2-600×50后天的亚马逊河载456个人的”东方之星”合金船,在亚马逊河上游沉没!引起我们关怀的还要,纷纷回想历史,翻开历史的小说去看看当年那多少个根本的沉船事故。

图片 1

早前平昔没境遇过这种情状,相对测量试验情状正式遇到比较复杂,何况预计或许是事先备份还原平昔没用过备份生龙活虎致性参数导致,何况发掘错误也未曾手工业检查(那些难点还在商量中,有遭受并知道源委的伙伴迎接教导)。

为了将来幸免因为复苏不如时导致的数码错过,非常计算本次故障进程和我们座谈、分享。

简化时间轴如下图:

发端—->备份主库—->恢复生机从库—->复制error1032,1062—->删除从库再次重作冯妇—->复制error1032,1062—->reset
master从库、主库—->图谋删除从库—->误操作删主库—–>恢复生机主库—–>跳过大批量1062、1032错误—->找drop
db地方恢复生机从库—->相比中央数据—->手工业补数据—->结束

下边根据笔者的记得描述下立即的风貌:

意气风发、第二遍备份主库、搭建从库

第三回搭建从库,从主库的备份未利用master-data=2
single-transaction(保险职业备份时的大器晚成致性)参数迁移后,报大批量1062和1032谬误(家家有本难念的经,非常的少说了)

 

图片 2

二、第4回复苏主库到从库

于是乎第二遍重复导入。

长期以来报错。在导入从库前使用reset master;将从库binlog淹没。

鉴于操作人士不停解reset master含义及试行结果,又在主库做了reset master;

结酚酞致主库全部binlog日志被毁灭并且binlog position置为1;

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

 

图片 3

重复导入发掘依旧大批量报1032,1062荒诞。

由于困惑是因为备份时没动用–single-transaction参数,绸缪删除从库,加参数重新备份主库。

三、误删除主库

结果误操作删除主库(那一个锅意气风发有的原因要甩给mysql
naivcat那几个工具,垂直排列库,稍稍不检点就便于点错。依旧建议大家听吴老师的用合法的workbench),删库仍然多人查对,在操作系统上实施,删前没把握最佳备份一回。

删库这种操作谨慎小心再小心,主要的工作说一遍!

删库这种操作谨小慎微再小心,首要的事体说三回!

删库这种操作谨言慎行再小心,主要的作业说三回!

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

这会儿为了确认保证专门的学业不中断,立马在主库上通过事先的备份文件苏醒了风流罗曼蒂克套库,当然数据一定错过了,但能够推算错过数据的岁月段(从备份达成开端—>DROP
DATABASE)。

PS.请不要问笔者干吗删库,为何删完又过来了生机勃勃套库,因为都不是自家干的。。。。。。

还好的是误删除主库但一直不删除从库,並且从库的io_thread依然处于yes状态(回想吴先生的科目,也正是说尽管库被剔除了但实则删库前的数目=备份数据+io_thread已下载的删除主库前的多少),由于sql_thread仍旧停到gtid靠前的职位

 

图片 4

四、跳过大批量1032,1062荒诞

其一时候纵然看下备份文件的gtid地方,并purge到该岗位(此前备份丢了,随意找了一个备份的截图,理解万岁)。

##那边说Bellamy下为什么一贯purge到备份的终极地点,因为书库备份的数目中1032和1062谬误太多,且主库已经删除不能通过脚本相比较跳过大量1032,1062破绽百出(吴老老师和朋友情提供),在能力所能达到保险是从主库逻辑备份过来的事态下(主从数据后生可畏致),大家选取连忙跳过多量乖谬(偷懒加处境急),直接purge到备份最后之处。

 

图片 5

##上海体育场面是随意截的二个备份文件最开端的岗位,请忽视这几个gtid的值,意思了然就行。

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

注:‘500’代表备份文件最终三个施行的事务的gtid。gtid_purged代表数据库已经在从库上海重机厂放过1-500这段专业。

五、找到主库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

 

图片 6

六、运维从库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就足以,再还原到主库就能够立即投入使用,还不会形成数据错过。

 

图片 7

担保从库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

留下评论

网站地图xml地图