最近有关注MySQL的一些备份，恢复的事情，想试着在MySQL上类似于Oracle的闪回（flashback）的功能
首先想到的是解析Binlog，然后逆向编写对应的SQL，去网上翻了翻资料，发现已经有大神实现了！但是仔细想了想，不管是自己写，还是直接用别人的成果，好像都挺麻烦的,毕竟懒癌晚期，找点简单的办法来取巧好了_(:з」∠)_
-----------------------------------------------------关于闪回特性的时机应用场景的 个人理解-------------------------------------------------------
从实际情况出发，闪回提供的数据恢复能力是相对偏弱，而且时间点也是相对不远，可能就是在几分钟前，但是闪回强在在数据恢复时间照比正常的恢复流程快很多
能用到闪回特性的实际场景，基本上就是DBA or 相关的技术人员在操作数据库的时候，由于失误 or 疏忽，在一些DDL或者DML语句中没有加上where，或者相似的表名写错了
PS:谁都有失误的时候T_T
在这种情境下,错误发生的时间点之后,且相关人员能第一时间发现,那么就可以用闪回了!
取巧的办法就在这个地方" 错误发生的时间点之后,且相关人员能第一时间发现",第一时间发现说明相隔时间并不长,那么,MySQL从库的数据如果存在一段时间的延迟,相关人员就能从从库直接导出相对应的数据,在主库上面进行恢复了~
-----------------------------------------------------------------这才是这篇博客的主题 -------------------------- ----------------------------------------
如何让从库对主库保持一个固定的延迟?
一般来说,按照网上的主从配置,配完之后,show slave status\G;之后，会在底部显示如下信息
翻阅MySQL的官方文档,里面有提到,在change master的设置里面,有一项master_delay=x秒的设置,把这一项添加进去以后,再启动主从,会变成如下信息
当然细心的人会发现这其实是两个不一样的MySQL,不过这并不影响测试,不要在意这些细节....
那么,这个参数设定以后,真的是延迟了600s再更新主库的数据变更么?我们可以来试试~
首先在看一下三个库的表结构,都是七张表,最左边的是主库,中间是延时从库,最右边的是另外一个普通的从库...
然后再主库上面新建一张表~
然后看一下时间和效果~
如截图可以看到延时从库并没有更新主库上的操作,而普通的从库已经更新了~这时候再去看一下延时从库的status~
还差好几分钟才会更新~
然后无聊的博主怒开了一波Dota2的不朽II箱子.....
纯金不朽碎骨锤一发~看看时间也差不多了,查看一下延时从库的status~
延时从库的更新在十分钟以后如约而至,然后继续回到了空闲状态~
所以用这种延时从库的办法,能自由的设置缓冲时间,来恢复错误的操作~
---------------------------------------------------------------------------华丽的分割线 ------------------------------------- ----------------------------------------
诚然,最开始想到的并不是这种官方的方法,第一时间是找了percona-toolkits去求助,使用里面的pt-slave-delay来达到延时从库的效果
pt-slave-delay的实现方法也很简单,定时在从库上执行stop slave和start slave,简单明了~
关于怎么去安装和使用pt-slave-delay就不在描述了,毕竟,官方的方法更加简单一些~不过percona-toolkits确实是一套很不错的工具集~
---------------------------------------------------------------------------华丽的全文完-----------------------------------------------------------------------------
首先想到的是解析Binlog，然后逆向编写对应的SQL，去网上翻了翻资料，发现已经有大神实现了！但是仔细想了想，不管是自己写，还是直接用别人的成果，好像都挺麻烦的,毕竟懒癌晚期，找点简单的办法来取巧好了_(:з」∠)_
-----------------------------------------------------关于闪回特性的时机应用场景的 个人理解-------------------------------------------------------
从实际情况出发，闪回提供的数据恢复能力是相对偏弱，而且时间点也是相对不远，可能就是在几分钟前，但是闪回强在在数据恢复时间照比正常的恢复流程快很多
能用到闪回特性的实际场景，基本上就是DBA or 相关的技术人员在操作数据库的时候，由于失误 or 疏忽，在一些DDL或者DML语句中没有加上where，或者相似的表名写错了
PS:谁都有失误的时候T_T
在这种情境下,错误发生的时间点之后,且相关人员能第一时间发现,那么就可以用闪回了!
取巧的办法就在这个地方" 错误发生的时间点之后,且相关人员能第一时间发现",第一时间发现说明相隔时间并不长,那么,MySQL从库的数据如果存在一段时间的延迟,相关人员就能从从库直接导出相对应的数据,在主库上面进行恢复了~
-----------------------------------------------------------------这才是这篇博客的主题 -------------------------- ----------------------------------------
如何让从库对主库保持一个固定的延迟?
一般来说,按照网上的主从配置,配完之后,show slave status\G;之后，会在底部显示如下信息
翻阅MySQL的官方文档,里面有提到,在change master的设置里面,有一项master_delay=x秒的设置,把这一项添加进去以后,再启动主从,会变成如下信息
当然细心的人会发现这其实是两个不一样的MySQL,不过这并不影响测试,不要在意这些细节....
那么,这个参数设定以后,真的是延迟了600s再更新主库的数据变更么?我们可以来试试~
首先在看一下三个库的表结构,都是七张表,最左边的是主库,中间是延时从库,最右边的是另外一个普通的从库...
然后再主库上面新建一张表~
然后看一下时间和效果~
如截图可以看到延时从库并没有更新主库上的操作,而普通的从库已经更新了~这时候再去看一下延时从库的status~
还差好几分钟才会更新~
然后无聊的博主怒开了一波Dota2的不朽II箱子.....
纯金不朽碎骨锤一发~看看时间也差不多了,查看一下延时从库的status~
延时从库的更新在十分钟以后如约而至,然后继续回到了空闲状态~
所以用这种延时从库的办法,能自由的设置缓冲时间,来恢复错误的操作~
---------------------------------------------------------------------------华丽的分割线 ------------------------------------- ----------------------------------------
诚然,最开始想到的并不是这种官方的方法,第一时间是找了percona-toolkits去求助,使用里面的pt-slave-delay来达到延时从库的效果
pt-slave-delay的实现方法也很简单,定时在从库上执行stop slave和start slave,简单明了~
关于怎么去安装和使用pt-slave-delay就不在描述了,毕竟,官方的方法更加简单一些~不过percona-toolkits确实是一套很不错的工具集~
---------------------------------------------------------------------------华丽的全文完-----------------------------------------------------------------------------
