简介：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管控会将该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进行裁剪

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

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