对于任何一家企业来讲，数据都是最宝贵的财富。

如何保护数据完整性，数据不受损坏，在发生故障时，如何保住数据，在发生误操作，黑客入侵，数据篡改等场景时，如何基于我们的备份来进行数据恢复，是每个技术人员需要关注的关键点。

阿里云致力于服务客户，为客户数据库提供连续数据保护、低成本的备份服务。它可以为多种环境的数据提供强有力的保护，以及强力恢复。在发生数据丢失、数据损坏的极端情况下，RDS管控平台具有一键还原的功能，基于客户设置的需要恢复的时间点，进行数据全方位恢复。

1. 按时间点恢复的技术实现

如果客户在某时间节点由于误操作，导致数据丢失，RDS管控服务是如何进行恢复的呢？

按时间点恢复的整体思路如下：一次完整的数据恢复是由物理备份+binlog恢复+binlog裁剪构成的。

图1

首先获取到可用的备份集，将备份集应用到目标实例上，然后再目标实例重放需要恢复的binlog文件，最后通过binlog裁剪的形式应用sql文件，实现整体的恢复。

2. 按时间点恢复的管控流程

1. 创建用于恢复的目的实例

当我们需要整体恢复源数据库数据时，我们首先需要创建一个与源实例同规格、同网络环境的目标实例。

为什么要这样做?

因为备份恢复属于高危操作，如果直接还原到源实例，一旦出现备份集不可用、binlog缺失等等问题，那么不仅丢失数据无法找回，甚至原数据都无法完好保住，所以强烈建议使用新实例来进行恢复！

2. 明确备份恢复时间点

当客户在执行了一系列数据库操作之后，如误删除、误修改等，操作之后无感知，等到业务受损、故障发生时，如何定位到当时操作的准确时间点用于数据恢复呢？

方式1：可以通过日志审计功能找到对应的误操作时间点。

方式2：可以将binlog解析成文本，查询对应的误操作时间点。

3. 通过备份历史获取可用的备份集

一般情况下，基于业务的重要程度，客户在云上会规划好自己的数据库备份周期，RDS管控会基于用户选择的恢复时间点自动寻找可用的物理备份集。

可见备份对于数据库的高可用和灾难恢复是重中之重的！

4. 获取备份集对应的binlog点位

专有云的备份一般都基于xtrabackup工具进行备份。xtrabackup具有热备份、恢复快等特点，同时会将备份结束时应用binlog的文件和点位写入相应文件中。RDS管控会将该binlogfile和binlogpos等信息写入数据库，当需要备份恢复时，会直接获取该点位进行恢复。

如下图所示：

图2

5. 将备份集还原至目的实例

1-4步骤为准备工作，下面开始正式的恢复数据。恢复数据的第一步是将获取的可用的全量物理备份集下载至目的实例上，并使用xtrabackup工具进行还原。

//首先要停止目的实例上的mysql进程

systemctl stop mysql

//然后合并数据,假设备份解压在/root/backup/目录下,可以指定需要恢复的实例端口，需加--defaults-file参数指定，默认3306。

innobackupex --apply-log /root/backup/

//删除原目录文件

rm -rf /data/mysql

//还原数据集,还原数据到哪个目录是基于配置文件my.cnf的datadir决定的。该字段一定要检查是否准确

innobackupex --copy-back /root/backup/

//目录赋权

chown -R mysql:mysql /data/mysql

6. 验证还原是否成功

管控服务需要验证还原是否成功，再决定是否需要向下操作，验证步骤也很简单粗暴，直接检查备份恢复日志中是否有ERROR,并且最后一行是否为completed OK!

如下图，为一次成功的备份恢复。

图3

7. 获取用于恢复的binlog日志

此步骤至关重要，关乎恢复是否成功，数据是否完整。

那么RDS管控服务如何获取正确的binlog来进行恢复呢？我们来看下图。

图4

例如当前我们的备份中总共有8个binlog备份(000-008)，首先通过物理备份记录的binlog的filename和pos来获取第一个binlog，如上图中的binlog004；然后通过客户设置的需要恢复的时间点的timestamp，来找到对应的最后一个binlog，如上图中的binlog007；最后将binlog004,binlog005,binlog006,binlog007这四个binlog备份下载到目的实例上进行恢复。

如果获取了错误的binlog日志用于恢复，比如误将binlog003/binlog005设置成了第一个binlog，那么binlog003/binlog005上执行的dml语句会在新实例上重新执行一次，恢复的数据就会增多或缺失；比如误将binlog0006或者binlog0008设置成了最后一个binlog，那么恢复的数据会缺失，且无法达到预期效果。

8. 重放relaylog

将下载的binlog复制到新实例的logdir中，并将除最后一个binlog(覆盖恢复时间点的binlog)之外的binlog重命名为relaylog，然后使用新实例重放这些relaylog。

//将binlog重命名,relaylog文件名可在mysql实例中执行show variables like '%relay%'查看.

rename mysql-bin MySQL2-relay-bin mysql-bin*

//将relay信息初始化到index文件中

ls ./MySQL2-relay-bin.0000*>MySQL2-relay-bin.index

//将这些文件复制到data文件中

cp MySQL2-relay-bin.*/data/mysql/

//文件赋权

chown -R mysql:mysql /data/mysql

//启动mysql实例

systemctl start mysql

//change master to一个不存在的实例，模拟此实例为一个备库,指定一个空的主库，创建SQL线程,然后根据备份记录的binlogfile和binlogpos来设置。并启动slave的sql_thread

CHANGE MASTER TO MASTER_HOST='1.1.1.1',RELAY_LOG_FILE='MySQL2-relay-bin.000011',RELAY_LOG_POS=160338;

START SLAVE SQL_THREAD;

show slave status\G

9. 验证relaylog重放成功

通过show slave status\G，来进行验证，此步骤一般恢复较慢，取决于数据库binlog个数及binlog大小。

验证1：查看relay_log_file字段的值是否为我们在MySQL2-relay-bin.index文件中维护的最大的值，如果是的话，则证明所有的bilog已重放成功；

验证2：查看Slave_SQL_Running字段是否为YES。

如下图所示：

图5

10. 通过mysqlbinlog功能裁剪恢复时间点上的binlog，并生成sql文件

至此，1-9步骤已经恢复了绝大部分数据了，剩余了一个覆盖我们恢复时间点的binlog未进行恢复。

那么我们如何来进行操作呢？

如下图所示：

图6

根据客户的时间点(如需要恢复至15:00的数据)，RDS管控需要将覆盖我们恢复时间点的binlog根据恢复时间进行裁剪，也就是只应用12:00-15:00的数据，15:00至18:00的数据属于误操作时间，不应该拿来应用。

//使用mysqlbinlog工具的裁剪功能对该binlog进行裁剪