关于sql:Mysql数据库按时间点恢复实战

28次阅读

共计 4219 个字符,预计需要花费 11 分钟才能阅读完成。

简介:Mysql 数据库按工夫点复原实战

对于任何一家企业来讲,数据都是最贵重的财产。

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

阿里云致力于服务客户,为客户数据库提供间断数据保护、低成本的备份服务。它能够为多种环境的数据提供强有力的爱护,以及强力复原。在产生数据失落、数据损坏的极其状况下,RDS 管控平台具备一键还原的性能,基于客户设置的须要复原的工夫点,进行数据全方位复原。

​​1. 按工夫点复原的技术实现​

如果客户在某工夫节点因为误操作,导致数据失落,RDS 管控服务是如何进行复原的呢?

按工夫点复原的整体思路如下:一次残缺的数据恢复是由物理备份 +binlog 复原 +binlog 裁剪形成的。

图 1

首先获取到可用的备份集,将备份集利用到指标实例上,而后再指标实例重放须要复原的 binlog 文件,最初通过 binlog 裁剪的模式利用 sql 文件,实现整体的复原。

2. 按工夫点复原的管控流程

1. 创立用于复原的目标实例

当咱们须要整体复原源数据库数据时,咱们首先须要创立一个与源实例同规格、同网络环境的指标实例。

为什么要这样做?

因为备份复原属于高危操作,如果间接还原到源实例,一旦呈现备份集不可用、binlog 缺失等等问题,那么不仅失落数据无奈找回,甚至原数据都无奈完整保住,所以强烈建议应用新实例来进行复原!

2. 明确备份复原工夫点

当客户在执行了一系列数据库操作之后,如误删除、误批改等,操作之后无感知,等到业务受损、故障产生时,如何定位到过后操作的精确工夫点用于数据恢复呢?

形式 1:能够通过日志审计性能找到对应的误操作工夫点。

形式 2:能够将 binlog 解析成文本,查问对应的误操作工夫点。

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

个别状况下,基于业务的重要水平,客户在云上会布局好本人的数据库备份周期,RDS 管控会基于用户抉择的复原工夫点主动寻找可用的物理备份集。

可见备份对于数据库的高可用和劫难复原是重中之重的!

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

专有云的备份个别都基于 xtrabackup 工具进行备份。xtrabackup 具备热备份、复原快等特点,同时会将备份完结时利用 binlog 的文件和点位写入相应文件中。RDS 管控会将该 binlogfilebinlogpos等信息写入数据库,当须要备份复原时,会间接获取该点位进行复原。

如下图所示:

图 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 进行裁剪

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 技术学院钉钉圈子,和更多云上人交换对于云平台的那些事。

版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

正文完
 0