简介：Mysql数据库按时间点恢复实战
对于任何一家企业来讲，数据都是最宝贵的财富。
如何保护数据完整性，数据不受损坏，在发生故障时，如何保住数据，在发生误操作，黑客入侵，数据篡改等场景时，如何基于我们的备份来进行数据恢复，是每个技术人员需要关注的关键点。
阿里云致力于服务客户，为客户数据库提供连续数据保护、低成本的备份服务。它可以为多种环境的数据提供强有力的保护，以及强力恢复。在发生数据丢失、数据损坏的极端情况下，RDS管控平台具有一键还原的功能，基于客户设置的需要恢复的时间点，进行数据全方位恢复。
如果客户在某时间节点由于误操作，导致数据丢失，RDS管控服务是如何进行恢复的呢？
按时间点恢复的整体思路如下：一次完整的数据恢复是由物理备份+binlog恢复+binlog裁剪构成的。
图1
首先获取到可用的备份集，将备份集应用到目标实例上，然后再目标实例重放需要恢复的binlog文件，最后通过binlog裁剪的形式应用sql文件，实现整体的恢复。
1. 创建用于恢复的目的实例
当我们需要整体恢复源数据库数据时，我们首先需要创建一个与源实例同规格、同网络环境的目标实例。
为什么要这样做?
因为备份恢复属于高危操作，如果直接还原到源实例，一旦出现备份集不可用、binlog缺失等等问题，那么不仅丢失数据无法找回，甚至原数据都无法完好保住，所以强烈建议使用新实例来进行恢复！
2. 明确备份恢复时间点
当客户在执行了一系列数据库操作之后，如误删除、误修改等，操作之后无感知，等到业务受损、故障发生时，如何定位到当时操作的准确时间点用于数据恢复呢？
方式1：可以通过日志审计功能找到对应的误操作时间点。
方式2：可以将binlog解析成文本，查询对应的误操作时间点。
一般情况下，基于业务的重要程度，客户在云上会规划好自己的数据库备份周期，RDS管控会基于用户选择的恢复时间点自动寻找可用的物理备份集。
可见备份对于数据库的高可用和灾难恢复是重中之重的！
专有云的备份一般都基于xtrabackup工具进行备份。xtrabackup具有热备份、恢复快等特点，同时会将备份结束时应用binlog的文件和点位写入相应文件中。RDS管控会将该binlogfile和binlogpos等信息写入数据库，当需要备份恢复时，会直接获取该点位进行恢复。
如下图所示：
图2
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
管控服务需要验证还原是否成功，再决定是否需要向下操作，验证步骤也很简单粗暴，直接检查备份恢复日志中是否有ERROR,并且最后一行是否为completed OK!
如下图，为一次成功的备份恢复。
图3
此步骤至关重要，关乎恢复是否成功，数据是否完整。
那么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，那么恢复的数据会缺失，且无法达到预期效果。
将下载的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
通过show slave status\G，来进行验证，此步骤一般恢复较慢，取决于数据库binlog个数及binlog大小。
验证1：查看relay_log_file字段的值是否为我们在MySQL2-relay-bin.index文件中维护的最大的值，如果是的话，则证明所有的bilog已重放成功；
验证2：查看Slave_SQL_Running字段是否为YES。
如下图所示：
图5
至此，1-9步骤已经恢复了绝大部分数据了，剩余了一个覆盖我们恢复时间点的binlog未进行恢复。
那么我们如何来进行操作呢？
如下图所示：
图6
根据客户的时间点(如需要恢复至15:00的数据)，RDS管控需要将覆盖我们恢复时间点的binlog根据恢复时间进行裁剪，也就是只应用12:00-15:00的数据，15:00至18:00的数据属于误操作时间，不应该拿来应用。
//使用mysqlbinlog工具的裁剪功能对该binlog进行裁剪 mysqlbinlog --start-position=4--stop-datetime='2021-04-23 15:00:00'-R -h127.0.0.1-uroot -pxxxx -P3306 mysql-bin.007>/tmp/mysql-bin.007.sql
在目的实例上执行该sql文件。
//赋权 chown mysql:mysql /tmp/mysql-bin.007.sql //恢复数据 mysql -uroot -pxxxx -h127.0.0.1-P3306 -f --max_allowed_packet=1073741824/root/mysql-bin.007.sql
至此，整体的备份恢复就已经完成了，下面就需要客户来进行验证数据，已经将目的实例的数据恢复到源实例中。
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。
原文链接：https://developer.aliyun.com/article/784887?
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
到此这篇关于Mysql数据库按时间点恢复实战的文章就介绍到这了,更多相关Mysql恢复数据库内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
