不得不说,在使用数据库的过程中,不管是业务开发者还是运维人员,都有可能对数据库进行误操作,运维人员对数据库有最大的操作权限,可以进行schema级别的操作,容易发生误删库或删表等错误的DDL操作。开发人员一般没有这么大的操作权限,但是同样能够造成灾难级的误操作,比如全表不带条件的update或delete等。
近期出现的几个线上库误操作,导致DBA着实忙碌了一阵,心有戚戚焉。虽然误操作有时候看起来防不胜防,但是办法总比问题多。下面简单聊聊误删除发生后,有哪些高效的补救措施。
第一种是延迟从库。在MySQL中,该功能从5.6开始支持,在此举5.7为例。
在建立延迟库复制关系时,除了复制有指定时间延迟外,其他跟普通从库相同。发现误删除后,可以停止从库复制,找到误删除发生的位置后,重启复制并指定要复制到的gtid或binlog位置。这样能精确恢复到出错前的位置。
接下来的办法很多,如果是表误删,可以使用延迟从库上的对应表来重建主库上的表数据。如果是全表update,可以使用从库上的表覆盖掉主库上的。
若要把延迟从库提升为主,则可通过配置filter来过滤掉误删除的时间区间内该表对应的binlog event,完成过滤复制后,再恢复成正常的复制关系完成数据复制。最后将其切换成主库即可。
当然,也可以使用mysqlbinlog工具来做上述的事情。延迟从库复制停掉后,可以使用mysqlbinlog精确回放到指定位置的binlog,mysqlbinlog支持表级的binlog event过滤。
在网易的MySQL分支中,mysqlbinlog支持过滤/指定某种类型的event,比如仅输出某库某表的update类型binlog event。
由于延迟从库平时不会有用户访问,所以其资源和规格可以尽可能降低。数据存储可以使用高压缩的存储引擎,比如MyRocks来。这样可以极大节省延迟从库的成本开销。
第二种是binlog增量备份,每个版本的MySQL都可以做,但是在基于gtid的复制上更容易做,在5.5版本上,要实现连续不间断的binlog复制是有难度的,需要处理主从切换等多种场景,因为主从切换后,binlog文件的索引和偏移位置都发生变化,需要找到主从库的binlog对应关系,而且5.5版本的从库一般没有开启binlog,这些都是难点。但对于基于gtid的复制,主从切换后,只需要从上次备份结束的事务gtid对应的binlog位置开始即可。相比基于文件偏移的增量备份,简单很多。
在进行恢复时,基于增量备份的误删除可以先恢复出一个误删除前的全量备份,再通过mysqlbinlog回放binlog到误删除位置,方法类似于第一种的mysqlbinlog使用方式。
第三种是flashback方案。这其实是成本最低的一种方法,又可以分为2种,ddl的flashback和dml的flashback。
其中ddl可通过将drop或truncate等变为rename来做,目前业界有些MySQL分支已经实现,InnoSQL 5.5版本开始支持基于binlog event的ddl flashback方式,最早由阿里云丁奇实现,但由于MySQL的ddl实现方案不断改进,原方式使用范围越来越小,另外,由于引入新的binlog event类型,会导致跟其他版本复制不兼容。目前正在实现无需binlog event参与的ddl flashback方式。
其实现方式类似于回收站,将rename的表重新rename回来。该方法的不足时容易引起磁盘空间占用过多,这可以通过过期清理回收站里的表来解决。
对于dml,可以将insert改为delete,delete改为insert,update对换前后项的方式进行。相应的工具有好几种,包括最经典的flashback,该功能最早由阿里云彭立勋实现,InnoSQL 5.5版本移植了源代码,并进行了针对性的优化和增强。一般情况下,发生误删除到发现,时间比较短,所以flashback所需的binlog是在的。这种方式的不足时需要binlog是row格式的,而且得保留完整的dml前后项,不过主流的MySQL数据库配置均支持。
一般线上库误删除的恢复都是DBA来做的。作为数据库内核维护者,仅提供相应的工具和恢复方案,从内核层面提供更加高效的方案和工具,是我们的责任。
了解更多mysqlbinlog使用小密码,请点击下面链接温正湖:mysqlbinlog工具使用的几个疑惑点和解释zhuanlan.zhihu.com