大家好，我是Leo。目前在常州从事Java后端。在上一篇文章中，我们介绍了在线数据库挂掉节点后，如何排查节点宕机问题。从select1、外部统计、内部统计等一系列流程方案介绍。本文将介绍在线数据库误删数据后是否跑路或如何解决！思路本文的介绍思路在下面的思维导图中进行了概括。也有助于读者更好的辨别可读性！误删一行应该是比较常见的。有时，为了解决数据问题，我们直接删除这一行。删了之后才发现我删错了。接下来就来介绍一下应该怎么处理吧！说到误删行，肯定涉及到两个参数：binlog_format=rowbinlog_row_image=FULLbinlog_format=row前面我们介绍binlog日志的时候就引入了这个参数。主要分为行式、语句式、混合式。这里为什么一定要设置成行，因为只有在记录详细的日志信息和恢复数据的时候才方便操作。声明肯定是不够的。mixed也是不一致的，因为根本不需要判断！binlog_row_image=FULL这是上述参数同时引入的新参数。目前有两种选择，FULL记录每一行的变化，minimal只记录受影响的行。默认使用FULL。进入正题。.....通过闪回工具可以通过闪回恢复数据。数据恢复的原理是修改binlog内容，带回主库重新加载。要使用当前方法，您还必须修改如下内容。对于insert语句，对应的binlog事件类型是Write_rows事件，改成Delete_rows事件即可；同样，对于delete语句，将Delete_rows事件改为Write_rows事件；而如果是Update_rows，则该数据行记录在binlog中，对于修改前和修改后的值，只需将这两行的位置互换即可。如果执行多个事务，比如本来是A，B，C，如果要恢复数据，直接倒序即可，即C，B，A建议：但是不建议直接从main执行图书馆。比较安全的方法是恢复备份，或者找一个从库作为临时库。对此临时库执行这些操作。然后将确认好的临时库数据恢复回主库。预防措施将sql_safe_updates参数设置为on。这样，如果我们在delete或update语句中忘记写where条件，或者where条件中不包含索引字段，那么执行这条语句就会报错。代码上线前，必须通过SQL审计。如果要删除的表数据量比较大，确认数据无用，不建议使用delete。这会生成并写入redologs、binlogs、rollbacklogs等。使用truncatetable或droptable命令可以节省性能。为什么使用truncatetable或droptable可以节省性能？正如我们上面提到的，必须设置binlog_format=row。这里要说明一下，虽然我们的配置没问题，但是内部机制有问题。使用这两个命令会自动设置为statement，所以这两个命令保存的日志比较简单。数据无法恢复。性能更好。如果删除了怎么办？如果误删了表/库，还是有办法的。不过麻烦一点。这也是最低底牌。全量备份+增量备份。该解决方案需要定期在线完整备份和实时备份。这种方案类似于Redis的AOF和RDB。那么他们是如何运作的呢？如果有人在中午12:00误删了一个库，做了最新的全量备份，如果备份时间是凌晨3:00，则每天备份一次。使用备份恢复临时数据库；从日志备份中取出凌晨3:00以后的日志；将所有这些日志应用到临时数据库中，除了有关意外删除数据的声明。扩展上述数据恢复，如果这个临时库中有多个数据库。使用mysqlbinlog命令时添加-database参数。指定表所在的库，避免恢复数据时搜索其他库的日志。如果使用GTID模式，会省去很多麻烦。只需要将未执行的gtid1添加到临时实例的GTID集合中，然后依次执行binlog即可。如果不使用GTID模式，还是挺麻烦的。只有应用于包含12个点的binlog文件时，先使用-stop-position参数执行误操作前的日志，再使用-start-position从误操作后的日志继续执行；性能优化这样一个过程，从性能上来说，是比较慢的，因为操作的往往是一个库，一个实例。如果您要恢复表，则没有必要。不是多余的，只是mysql不能指定只解析一张表的log。加速方法从备份中恢复临时实例后，将临时实例设置为在线备库的从库。在保存主从配置之前，通过执行changereplicationfilterreplicate_do_table=(tbl_name)命令，临时库只能同步误操作的表。这样做还可以利用前面介绍的并行复制技术来加速整个数据恢复过程。日志丢失如果在寻找日志恢复实例时，临时实例需要的binlog在备库上已??经被删除了，我们可以从binlog备份系统中找到需要的binlog，并放回备库中。具体操作如下：先下载丢失的两条日志，放到备库的log目录下，打开log目录下的master.index文件，在文件开头添加两行，内容为./master.missing001和./master.Lost002重启备库，重新加载两个日志。这时候主从关系的建立就可以正常同步了。考虑到磁盘硬件要求，必须要求备份系统定期备份全量日志。能够适当节省固定天数延迟复制备库的方案是日志延迟方案。比如从备库写入一条数据，数据不会立即同步到备库。然后使用delay方式同步到备库。例如，我们延迟1小时。主库写入数据后，1小时后同步到从库。然后如果1小时内发现数据有误，可以使用stopslave命令停止写入数据。可以使用CHANGEMASTERTOMASTER_DELAY=N命令指定备库继续与主库保持N秒的延迟。为防止表/库方法账户分离，不同的业务人员有不同的操作权限。避免编写错误的命令。制定操作规范。这样做的目的是为了避免把要删除的表名写错。删除数据的风险相对较高。一般这种情况只能用集群来恢复。如果没有集群，就只能打嗝了。如果只删除一个节点，HA系统就会开始工作，先选择一个新的主库，然后恢复这个节点上的数据，然后再访问整个集群。这将解决它。为了安全起见，rm命令一般危害更大。建议扩展机房，跨城市保存数据。总结今天，我们介绍了除了跑路之外，我们还有哪些处理删除数据的方法，以及数据删除后的响应和应急预案。
