最近经常遇到开发同学在线上误操作数据，有的是误操作了一张表下的某些数据，还有的是表被删掉了，甚至也有整个库被误删。开发同学遇到这种情况通常是匆匆忙忙的找到DBA，问问有没有补救的办法，这时候DBA则会去看看这数据库有没有备份，备份可不可用，虽说这正是体验DBA价值的时候，但是处理一个SQL的误操作可能需要几个小时甚至一天的时间，其实整个过程并不好受。如何避免这样的情况，有没有更加效率的处理办法？

缩小用户权限

个人账号直接操作线上数据库是不合理的，并且用户在使用的过程中，测试和线上窗口来回切换，非常容易会把线上数据当成测试库直接改掉，并且自己全然不知。针对这种情况应联系开发同学确认其到底需要什么权限，用不到的权限建议回收掉。另外用户在用个人账户连线上数据库的时候SQL执行完就应立即退出Session，不要开了很多窗口挂在那里，非常容易误操作，良好的使用习惯也能够大大降低误操作的发生。

数据备份是最重要的一棵救命稻草

案例一：之前遇到过一次：某线上系统整个DataBase都被误删，导致整个服务不可用，当时这个数据库处于无人托管的状态，也没有备份程序，所以整个恢复过程非常吃力,之后了解到有个QA同学前几天刚好前几天有过对这个库做过一次全量的DUMP用来做测试，后来的恢复也全靠这份DUMP的数据，现在想起来也心有余悸，所以对DBA来说一定要确保所有的线上环境都有完整并且可用的数据库备份。

DBA高效响应用户需求才能体现价值

我们经常会遇到的情况是：当用户误删数据时，我们备份都有，但是做的时候才发现把这些备份都恢复出来其实是个挺费时间的工作。

案例二：线上某核心产品用户数据被开发误更新，导致用户个人信息有有一列数据错误，开发同学火急火燎的要马上恢复导误更新之前的状态，但是实际情况是这个产品使用的是分布式数据库，底层所使用的是多个MySQL实例，DBA需要手动的把这几个MySQL的备份一个一个找出来然后再从网上或者别的服务器上拷贝一个恢复程序，然后自己再人肉拼恢复命令，整个过程还涉及到把这个备份从备份服务器上远程COPY出来，恢复完成后再通过做Slave回放Binlog，所以整个过程都有可能超过几个小时甚至半天，如果能把整个过程自动化掉，通过程序一键帮助我们恢复导一个我们指定的时间点，其实可以节省很多时间，并且也减轻DBA的负担，对用户的影响也会更少一点。

数据库合理配置

很多数据误删的情况大多是一个Update或者一个DELETE，可能影响到的只是几十行或者几百行的数据，这样我们再去拉备份做同步无非是显得有点小题大作，有没有更效率的方法解决问题呢？

大家都知道Oracle数据库有个闪回功能，能够自动的把最近一段时间内的数据恢复，那么MySQL有这样的东西吗？官方MySQL版本其实是没有这样的工具的，但是作为开源数据库的领头羊，MySQL吸纳了太多有意思的功能，MySQL的 FlashBack就是其中的一个。

这个Patch的实现思路还算比较简单，举例说：比如用户在时间点T1把表T从1改成了2，然后在时间点T2把表T从2改成3，那么如何把表T恢复到T1的时间点呢？这个工具通过解析BINLOG的方式完成回滚，因为用户其实在T1和T2两个时间点做了两个UPDATE，所以工具要做的只是根据BINLOG里面的内存把这两个UPDATE逆向解析并执行就OK了，所以会帮我们自动的转化为Update T 3--->2 , UpdateT 2--->1 ， 这样就完成了数据的回滚，但是这个工具依赖于MySQLBinlog的格式必须要求binlog_format是ROW才能解析，因为在解析的构成中需要从BinlOG里面获得很多元数据信息。

该Patch最早来源于淘宝，后来我们公司内部MySQL分支版本：InnoSQL 已经把这个功能吸纳进到了我们的版本中，并且我们在他的基础上进行了加强，因为他只能完成DML的回滚，DDL的回滚是无能为力的，我们在它的基础上完善了DDL的回滚，当然也非常感谢淘宝贡献了这么好的PATCH与想法。这样的话通过这个工具即使没有数据库备份，只有有BINLOG并且日志级别是ROW的话也能非常快的完成数据的回滚操作，简化了操作流程。

延迟镜像可能是恢复数据的最后一根救命稻草

案例三：之前线上有个非常大的数据库，数据量:>1T ，写入量非常大，属于后台系统但是数据非常重要，每天很多人都要用到这个系统。因为这个库非常大导致数据库的备份功能很难进行，因为没有充足的存储资源做备份，刚巧开发同学一个误操作把这个系统的用户表更新掉了，把所有人的mobile更新成一个手机号，因为这是运维监控系统，所以误操作完之后这个手机号就开始疯狂的收报警信息...当时可以确认的是这个库没有备份，并且BINLOG的格式不是ROW，在几乎毫无办法的情况下惊喜的发现这个库竟然有个从库延迟了半天左右，当时真的是惊喜若狂，马上停掉镜像进行恢复，在MySQL5.6版本之前可以使用Percona的第三方工具完成延迟从库的功能，在MySQL5.6版本之后官方版本就提供了延迟从库的功能。

数据误更新对产品和DBA来说都是一件不愿意看到的事情，所以在分配线上数据库权限的时候一定要细化，个人账户尽可能的只申请最小权限。开发同学在使用数据库查询的时候也要养成良好的使用习惯，不要多个窗口同时开着，也不要线上和测试同时开着。另外DBA在遇到这种情况的时候还是需要冷静处理，要定时对备份做巡检确保备份都是可用且可靠的，MySQL线上Binlog格式尽量全部改成ROW格式，核心业务配上一个延迟从库，关键时候可能会救命。

最后愿天下再也没有误操作。

网易云信∣真正稳定的IM云服务

ID：neteaseim  长按识别，关注精彩