2023年11月24日发(作者：)
Mysql数据库按时间点恢复实战
简介：简介：Mysql数据库按时间点恢复实战
对于任何⼀家企业来讲，数据都是最宝贵的财富。
如何保护数据完整性，数据不受损坏，在发⽣故障时，如何保住数据，在发⽣误操作，⿊客⼊侵，数据篡改等场景时，如何基于我们的备份
来进⾏数据恢复，是每个技术⼈员需要关注的关键点。
阿⾥云致⼒于服务客户，为客户数据库提供连续数据保护、低成本的备份服务。它可以为多种环境的数据提供强有⼒的保护，以及强⼒恢
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
//还原数据集,还原数据到哪个⽬录是基于配置⽂件的datadir决定的。该字段⼀定要检查是否准确
innobackupex --copy-back /root/backup/
//⽬录赋权
chown -R mysql:mysql /data/mysql
6. 验证还原是否成功
管控服务需要验证还原是否成功，再决定是否需要向下操作，验证步骤也很简单粗暴，直接检查备份恢复⽇志中是否有ERROR,并且最后⼀
⾏是否为completed OK!
如下图，为⼀次成功的备份恢复。
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-
//将这些⽂件复制到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 statusG
9. 验证relaylog重放成功
通过show slave statusG，来进⾏验证，此步骤⼀般恢复较慢，取决于数据库binlog个数及binlog⼤⼩。
验证1：查看relay_log_file字段的值是否为我们在⽂件中维护的最⼤的值，如果是的话，则证明所有的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进⾏裁剪
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
11. ⽬的实例通过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
12. 验证数据
⾄此，整体的备份恢复就已经完成了，下⾯就需要客户来进⾏验证数据，已经将⽬的实例的数据恢复到源实例中。
我们是阿⾥云智能全球技术服务-SRE团队，我们致⼒成为⼀个以技术为基础、⾯向服务、保障业务系统⾼可⽤的⼯程师团队；提供专业、
体系化的SRE服务，帮助⼴⼤客户更好地使⽤云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业
客户上云、⽤好云，让客户云上业务运⾏更加稳定可靠的技术，您可⽤钉钉扫描下⽅⼆维码，加⼊阿⾥云SRE技术学院钉钉圈⼦，和更多云
上⼈交流关于云平台的那些事。
版权声明：版权声明：本⽂内容由阿⾥云实名注册⽤户⾃发贡献，版权归原作者所有，阿⾥云开发者社区不拥有其著作权，亦不承担相应法律责
任。具体规则请查看《阿⾥云开发者社区⽤户服务协议》和《阿⾥云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄
袭的内容，填写侵权投诉表单进⾏举报，⼀经查实，本社区将⽴刻删除涉嫌侵权内容。
发布评论