简介:Mysql数据库按时间点恢复实战
对于任何一家企业来说,数据都是最宝贵的财富。mysql
如何保护数据完整性,数据不受损坏,在发生故障时,如何保住数据,在发生误操做,黑客入侵,数据篡改等场景时,如何基于咱们的备份来进行数据恢复,是每一个技术人员须要关注的关键点。sql
阿里云致力于服务客户,为客户数据库提供连续数据保护、低成本的备份服务。它能够为多种环境的数据提供强有力的保护,以及强力恢复。在发生数据丢失、数据损坏的极端状况下,RDS管控平台具备一键还原的功能,基于客户设置的须要恢复的时间点,进行数据全方位恢复。数据库
若是客户在某时间节点因为误操做,致使数据丢失,RDS管控服务是如何进行恢复的呢?网络
按时间点恢复的总体思路以下:一次完整的数据恢复是由物理备份+binlog恢复+binlog裁剪构成的。app
图1工具
首先获取到可用的备份集,将备份集应用到目标实例上,而后再目标实例重放须要恢复的binlog文件,最后经过binlog裁剪的形式应用sql文件,实现总体的恢复。阿里云
当咱们须要总体恢复源数据库数据时,咱们首先须要建立一个与源实例同规格、同网络环境的目标实例。spa
为何要这样作?线程
由于备份恢复属于高危操做,若是直接还原到源实例,一旦出现备份集不可用、binlog缺失等等问题,那么不只丢失数据没法找回,甚至原数据都没法无缺保住,因此强烈建议使用新实例来进行恢复!日志
当客户在执行了一系列数据库操做以后,如误删除、误修改等,操做以后无感知,等到业务受损、故障发生时,如何定位到当时操做的准确时间点用于数据恢复呢?
方式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技术学院钉钉圈子,和更多云上人交流关于云平台的那些事。
本文内容由阿里云实名注册用户自发贡献,版权归原做者全部,阿里云开发者社区不拥有其著做权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将马上删除涉嫌侵权内容。