mysql之 innobackupex备份+binlog日志的完全恢复(命令行执行模式)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

前言:
MySQL的完全恢复,我们可以借助于完整的 备份+binlog 来将数据库恢复到故障点。
备份可以是热备与逻辑备份(mysqldump),只要备份与binlog是完整的,都可以实现完全恢复。

1. 准备实验环境
mysql> select version();
+------------+
| version() |
+------------+
| 5.6.25-log |
+------------+
1 row in set (0.00 sec)
mysql> create database com_rec;
Query OK, 1 row affected (0.00 sec)
mysql> use inc_rec;
Database changed
mysql> create table andy (id int);
Query OK, 0 rows affected (0.08 sec)
mysql> insert into andy values(1),(2);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
2. 全备
[root@mysql02 full]# innobackupex --defaults-file=/etc/my.cnf --user=root --password=oracle --port=3606 /xtrabackup/full/
xtrabackup: Transaction log of lsn (1662519) to (1662519) was copied.
170609 17:34:34 completed OK!
3. 查看全备生成文件
[root@mysql02 full]# ll /xtrabackup/full/
total 4
drwxr-x---. 6 root root 4096 Jun 9 17:34 2017-06-09_17-34-30
4. 模拟业务新数据
mysql> insert into andy values(3),(4);
Query OK, 2 rows affected (0.14 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
5. 增量备份
-- 创建存放增量备份目录并赋权
[root@mysql02 full]# mkdir -p /xtrabackup/incr/
[root@mysql02 full]# chown -R mysql:mysql /xtrabackup/incr/
[root@mysql02 full]# ll /xtrabackup/
total 8
drwxr-xr-x. 3 mysql mysql 4096 Jun 9 03:53 full
drwxr-xr-x. 2 mysql mysql 4096 Jun 9 04:00 incre
-- 正式开始增量备份
[root@mysql02 full]# innobackupex --defaults-file=/etc/my.cnf --user=root --password=oracle --incremental \
--incremental-basedir=/xtrabackup/full/2017-06-09_17-34-30/ /xtrabackup/incr/
########################################下面是增量备份输出
。。。省略
xtrabackup: Transaction log of lsn (1665808) to (1665808) was copied.
170609 17:36:46 completed OK!
6. 再模拟新业务,该记录在保存在binlog,而不会存在于任何备份,这条记录用于验证完全恢复 
mysql> insert into andy values(5);
Query OK, 1 row affected (0.00 sec)
7. 记下操作后的 position 点
mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000005 | 1104 | | | |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
8. 切换binlog日志
mysql> flush logs;
Query OK, 0 rows affected (0.00 sec)
9. 使用binlog events命令来查看我们最后insert的一条记录 
mysql> show binlog events in 'binlog.000005';
+---------------+------+-------------+-----------+-------------+-----------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+------+-------------+-----------+-------------+-----------------------------------------------+
| binlog.000005 | 4 | Format_desc | 1 | 120 | Server ver: 5.6.25-log, Binlog ver: 4 |
| binlog.000005 | 120 | Query | 1 | 221 | drop database inc_rec |
| binlog.000005 | 221 | Query | 1 | 324 | create database com_rec |
| binlog.000005 | 324 | Query | 1 | 430 | use `com_rec`; create table andy (id int) |
| binlog.000005 | 430 | Query | 1 | 515 | BEGIN |
| binlog.000005 | 515 | Query | 1 | 625 | use `com_rec`; insert into andy values(1),(2) |
| binlog.000005 | 625 | Xid | 1 | 656 | COMMIT /* xid=67 */ |
| binlog.000005 | 656 | Query | 1 | 741 | BEGIN |
| binlog.000005 | 741 | Query | 1 | 851 | use `com_rec`; insert into andy values(3),(4) |
| binlog.000005 | 851 | Xid | 1 | 882 | COMMIT /* xid=81 */ |
| binlog.000005 | 882 | Query | 1 | 967 | BEGIN |
| binlog.000005 | 967 | Query | 1 | 1073 | use `com_rec`; insert into andy values(5) |
| binlog.000005 | 1073 | Xid | 1 | 1104 | COMMIT /* xid=96 */ |
| binlog.000005 | 1104 | Rotate | 1 | 1148 | binlog.000006;pos=4 |
+---------------+------+-------------+-----------+-------------+-----------------------------------------------+
14 rows in set (0.00 sec)

10. 查看binlog的位置 与 datadir 的位置, 防止 mv datadir时误操作 binlog ,影响恢复 (binlog与datadir一定要分开放置)
mysql> show variables like '%log_bin%';
+---------------------------------+------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------+
| log_bin | ON |
| log_bin_basename | /data/mysql/binarylog/binlog |
| sql_log_bin | ON |
+---------------------------------+------------------------------------+
6 rows in set (0.00 sec)

mysql> show variables like '%datadir%';
+---------------+--------------+
| Variable_name | Value |
+---------------+--------------+
| datadir | /data/mysql/ |
+---------------+--------------+
1 row in set (0.00 sec)
11. 恢复
11.1 先做基于全备的apply,注意,此时使用了--redo-only 
[root@mysql02 full]# innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log --redo-only /xtrabackup/full/2017-06-09_17-34-30/
170609 04:19:30 completed OK!
11.2 在恢复增量备份集: --此时没有--redo-only,如果有多个增备,仅仅最后一个增备无需指定--redo-only 
[root@mysql02 full]# innobackupex --defaults-file=/etc/my.cnf --user=root --apply-log /xtrabackup/full/2017-06-09_17-34-30/ --incremental-dir=/xtrabackup/incr/2017-06-09_17-36-39/
170609 04:24:45 completed OK! #结果出现completed OK表示完全成功
说明: /xtrabackup/full/2017-06-09_17-34-30/ 为全备基目录 , incremental-dir 为增量备份目录
12. 关闭要恢复的实例
[root@mysql02 data]# /etc/init.d/mysql stop -p3306
netstat -nltp|grep mysql|grep 3606 
13.将原有文件夹重命名到新位置,并创建原文件夹 
[root@mysql02 full]# mv /data/mysql /data/mysqlbak
[root@mysql02 full]# mkdir -p /data/mysql
14.执行拷贝恢复的文件到原来的数据位置
[root@mysql02 full]# innobackupex --defaults-file=/etc/my.cnf --user=root --copy-back /xtrabackup/full/2017-06-09_17-34-30/
170609 04:33:06 completed OK! #结果出现completed OK表示完全成功
说明: /xtrabackup/full/2017-06-09_17-34-30/ 为全备基目录
15. 权限修改
[root@mysql02 ~]# mkdir -p /data/mysql/binarylog (说明:这里我binlog在datadir在路径下,所以要单独为binlog创建目录)
-- 将binlog日志mv回原位置 (如果binlog不在datadir下,就不用操作)
[root@mysql02 xtrabackup]# ll /data/mysqlbak/binarylog/
total 28
-rw-rw----. 1 mysql mysql 164 Jun 9 06:12 binlog.000001
-rw-rw----. 1 mysql mysql 386 Jun 9 06:14 binlog.000002
-rw-rw----. 1 mysql mysql 143 Jun 9 06:53 binlog.000003
-rw-rw----. 1 mysql mysql 143 Jun 9 07:35 binlog.000004
-rw-rw----. 1 mysql mysql 1148 Jun 9 17:45 binlog.000005
-rw-rw----. 1 mysql mysql 143 Jun 9 17:48 binlog.000006
-rw-rw----. 1 mysql mysql 216 Jun 9 17:45 binlog.index

[root@mysql02 data]# mv /data/mysqlbak/binarylog/* /data/mysql/binarylog/
[root@mysql02 xtrabackup]# ll /data/mysql/binarylog/
total 28
-rw-rw----. 1 mysql mysql 164 Jun 9 06:12 binlog.000001
-rw-rw----. 1 mysql mysql 386 Jun 9 06:14 binlog.000002
-rw-rw----. 1 mysql mysql 143 Jun 9 06:53 binlog.000003
-rw-rw----. 1 mysql mysql 143 Jun 9 07:35 binlog.000004
-rw-rw----. 1 mysql mysql 1148 Jun 9 17:45 binlog.000005
-rw-rw----. 1 mysql mysql 143 Jun 9 17:48 binlog.000006
-rw-rw----. 1 mysql mysql 216 Jun 9 17:45 binlog.index

[root@mysql02 data]# chown -R mysql:mysql /data/mysql
16. 启动恢复后的实例 
mysqld_safe --defaults-file=/etc/my.cnf &
17. 登录检查
[root@mysql02 ~]# mysql -uroot -poracle
mysql> use com_rec
mysql> select * from andy;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 | 
| 4 | > 恢复成功,但是没有恢复到最新,缺少 id=5 , 'Inbinlog'记录并没有被恢复 。 
+------+
18. 使用binlog做完全恢复
[root@mysql02 ~]# cd /xtrabackup/incr/2017-06-09_17-36-39/
--从innobackupex获得binlog的位置 
[root@mysql02 2017-06-09_17-36-39]# more xtrabackup_binlog_info 
binlog.000005 882
--使用mysqlbinlog 追加的最新 
[root@mysql02 2017-06-09_17-36-39]# mysqlbinlog --start-position=882 --stop-position=1104 /data/mysql/binarylog/binlog.000005 | mysql -uroot -poracle 
补充:
这样做确实可以,而且row模式的binlog,也可以通过这种方式来执行。但是这样做有几个缺点
a. 如果解析出来的binlog在执行的过程中报错,如何处理?直接加 -f 强制执行吗?
b. 执行中途如何停下来,下次接着跑? 比如我想调整一下MySQL的参数(需要重启)后继续跑?
c. 只能单线程执行。而且mysqlbinlog解析再通过管道执行,有比较高的性能开销。
19. 验证,可以看到最后一条记录以及被恢复
mysql> select * from andy;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+
5 rows in set (0.00 sec)

总结
a、对于完全恢复,我们需要使用备份加binlog两者结合的方式来实现
b、在恢复期间,首先使用带read-only的apply-log方式来prepare全备
c、接下来使用带read-only的apply-log方式来prepare增备,仅最后一个增备可以不用read-only
d、停止原有实例,并copy-back后启动恢复后的实例
e、从Innobakcupex备份信息中获取最后的binlog日志及位置信息
f、使用mysqlbinlog方式将日志追加到最新时刻

 

文章可以转载,必须以链接形式标明出处。


本文转自 张冲andy 博客园博客,原文链接: http://www.cnblogs.com/andy6/p/6970837.html   ,如需转载请自行联系原作者
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
7天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
113 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1630 14
|
4天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL的撤销日志文件和错误日志文件
本文介绍了MySQL的物理存储结构,重点讲解了InnoDB存储引擎中的撤销日志文件(undo log)和错误日志文件。从MySQL 8.0开始,默认生成两个10MB的undo表空间文件,并支持动态扩容和收缩。错误日志文件记录了MySQL启动、运行、关闭过程中的问题,通过示例展示了如何查看和使用这些日志。
|
1月前
|
SQL 存储 关系型数据库
Mysql主从同步 清理二进制日志的技巧
Mysql主从同步 清理二进制日志的技巧
27 1
|
1月前
|
关系型数据库 MySQL 数据库
DZ社区 mysql日志清理 Discuz! X3.5数据库可以做定期常规清理的表
很多站长在网站日常维护中忽略了比较重要的一个环节,就是对于数据库的清理工作,造成数据库使用量增加必须多的原因一般有2个:后台站点功能开启了家园,此功能现在很少有论坛会用到,但是灌水机会灌入大量垃圾信息致使站长长时间未能发觉;再有就是程序默认的一些通知类表单会存放大量的、对于网站日常运行并无意义的通知信息。
68 2
|
26天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
53 0
|
3月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
159 0
|
12天前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
119 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
1月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
219 3
|
3月前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
131 3