MySQL备份恢复的一种新的尝试

这是学习笔记的第 1902 篇文章

今天梳理了一下备份恢复方向的内容，目前备份方向已经充分验证了功能，在数据恢复方向的功能可行，但是在性能和效率上还是存在较大的改进空间。

数据恢复的场景目前根据业务需求主要有两类：

1. 基于指定表数据的快速恢复
2. 基于时间点的数据恢复 其中第一个场景更为常见，因为发生误操作或者数据异常的情况下，常常是对部分表进行数据恢复。而之前的很多方案都是全库的恢复，其实恢复的过程中会有太多的资源损耗，完全可以做到定制化的恢复。 比如一个数据库有800G,某个数据表有5G,如果要恢复这张表的数据到一个指定的时间点，我们需要先做全库恢复，然后从中找到指定的表然后开始做基于时间点的binlog恢复。通常瓶颈都在那795G的数据恢复过程中，这个资源消耗相对是比较大的。 如果恢复后发现数据不符合预期，可能还要做多次恢复尝试，那么我们是否能够平滑的支撑这个需求呢，我们需要引入RecoverDB这个角色，它是单纯为了恢复单表而创建的一个测试数据库，可以通过.frm，.ibd文件实现单表数据的恢复。一个相对完整的流程设计如下：

同时对于部分备份量较大的数据，可以考虑下沉到HDFS中进行归档。