基于Innobackupex的全备恢复

    对于MySQL数据库的热备,xtrabackup是大多数DBA朋友们的选择。xtrabackup内嵌了一个innobackupex可用于热备MySQL数据库。本文描述了基于innobackupex这个工具全备下的恢复并给出演示供大家参考。     有关Innobackupex的全备可参考:Innobackupex 全备数据库

1、Innobackupex恢复原理     After creating a backup, the data is not ready to be restored. There might be uncommitted transactions to be undone or transactions in the logs to be replayed. Doing those pending operations will make the data files consistent and it is the purpose of the prepare stage. Once this has been done, the data is ready to be used.     To prepare a backup with innobackupex you have to use the --apply-log and the path to the backup directory as an argument:

    Innobackupex replayed the committed transactions in the log files (some transactions could have been done while the backup was being done) and rolled back the uncommitted ones. Once this is done, all the information lay in the tablespace (the InnoDB files), and the log files are re-created.

    在备份期间(copy数据时)事务存在不一致,即copy开始时,有些事务已开始,有些刚刚开始,而copy结束前或结束后才提交或回滚。     这些不确定的事务需要在恢复前来确定最终是否最终提交或回滚。在这个阶段的操作称之为prepare阶段。     这个prepare阶段依赖于备份时的xtrabackup log(来自innodb logfile),使用--apply-log参数实现一致性。     --apply-log参数会根据xtrabackup log做相应的前滚或回滚,完成后会重建innodb logfile文件。

    The --use-memory option The preparing process can be speed up by using more memory in it. It depends on the free or available RAM on your system, it defaults to 100MB. In general, the more memory available to the process,the better. The amount of memory used in the process can be specified by multiples of bytes:     恢复期间,--use-memory选项可以加速prepare过程,如果系统可用内存够大的话,该值缺省被设置为100MB。

Innobackupex恢复示意图

2、演示恢复全备

a、当前环境
robin@localhost[(none)]> show variables like 'version';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| version       | 5.6.12-log |
+---------------+------------+

robin@localhost[(none)]> create database fullbakdb;
Query OK, 1 row affected (0.01 sec)

robin@localhost[(none)]> use fullbakdb

robin@localhost[fullbakdb]> create table tb(id smallint,val varchar(20));

robin@localhost[fullbakdb]> insert into tb values(1,'robin'),(2,'leshami');

robin@localhost[fullbakdb]> select * from tb;
+------+---------+
| id   | val     |
+------+---------+
|    1 | robin   |
|    2 | leshami |
+------+---------+

b、全备数据库
SHELL> innobackupex --user=robin -password=xxx --port=3606 --socket=/tmp/mysql3606.sock \  
> --defaults-file=/data/inst3606/data3606/my3606.cnf /data/bak/hotbak  

-- 下面是备份完成后的内容
SHELL>  pwd
/data/bak/hotbak
SHELL>  ll
drwxr-xr-x 7 root root 4096 2014/12/22 09:04 2014-12-22_09-04-05

--查看备份生成的相关文件
SHELL>  ll 2014-12-22_09-04-05
total 77944
-rw-r--r-- 1 root root      357 2014/12/22 09:04 backup-my.cnf
drwx------ 2 root root     4096 2014/12/22 09:04 fullbakdb
-rw-r----- 1 root root 79691776 2014/12/22 09:04 ibdata1
drwx------ 2 root root     4096 2014/12/22 09:04 mysql
drwxr-xr-x 2 root root     4096 2014/12/22 09:04 performance_schema
drwx------ 2 root root     4096 2014/12/22 09:04 recover
drwx------ 2 root root     4096 2014/12/22 09:04 sakila
-rw-r--r-- 1 root root       26 2014/12/22 09:04 xtrabackup_binlog_info
-rw-r----- 1 root root       93 2014/12/22 09:04 xtrabackup_checkpoints
-rw-r--r-- 1 root root      684 2014/12/22 09:04 xtrabackup_info
-rw-r----- 1 root root     2560 2014/12/22 09:04 xtrabackup_logfile

c、清空表tb以便测试恢复功能
robin@localhost[fullbakdb]> truncate table tb;
Query OK, 0 rows affected (0.01 sec)

robin@localhost[fullbakdb]> select * from tb;
Empty set (0.00 sec)

d、恢复全备
--关闭原有实例
SHELL> mysqldown -P3606
SHELL> netstat -nltp|grep mysql|grep 3606

--准备全备文件
SHELL> innobackupex --apply-log --user=robin -password=xxx --port=3606 --socket=/tmp/mysql3606.sock \
> --defaults-file=/data/inst3606/data3606/my3606.cnf /data/bak/hotbak/2014-12-22_09-04-05

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
            ......非重要信息忽略,下同......
xtrabackup: Starting InnoDB instance for recovery.  --开始innodb实例恢复
            ...........
InnoDB: Starting crash recovery.    --开始crash recovery
            ...........
141222 09:13:59  innobackupex: Restarting xtrabackup with command: xtrabackup  --defaults-file="/data/inst3606/data3606/my3606.cnf" 
--defaults-group="mysqld" --prepare --target-dir=/data/bak/hotbak/2014-12-22_09-04-05 --tmpdir=/tmp
for creating ib_logfile*           --注意这里,使用了--prepare,并且创建innodb的logfile

xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: using the following InnoDB configuration for recovery:
             ............
-- Author : Leshami
-- Blog   : http://blog.csdn.net/leshami    
InnoDB: Shutdown completed; log sequence number 391275633
141222 09:14:02  innobackupex: completed OK!        --成功恢复 

--查看恢复后文件的相关信息
SHELL>  ll 2014-12-22_09-04-05
total 178404
-rw-r--r-- 1 root root      357 2014/12/22 09:04 backup-my.cnf
drwx------ 2 root root     4096 2014/12/22 09:04 fullbakdb
-rw-r----- 1 root root 79691776 2014/12/22 09:14 ibdata1
-rw-r--r-- 1 root root 50331648 2014/12/22 09:14 ib_logfile0
-rw-r--r-- 1 root root 50331648 2014/12/22 09:13 ib_logfile1
drwx------ 2 root root     4096 2014/12/22 09:04 mysql
drwxr-xr-x 2 root root     4096 2014/12/22 09:04 performance_schema
drwx------ 2 root root     4096 2014/12/22 09:04 recover
drwx------ 2 root root     4096 2014/12/22 09:04 sakila
-rw-r--r-- 1 root root       26 2014/12/22 09:04 xtrabackup_binlog_info
-rw-r--r-- 1 root root       24 2014/12/22 09:14 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root       93 2014/12/22 09:14 xtrabackup_checkpoints
-rw-r--r-- 1 root root      684 2014/12/22 09:04 xtrabackup_info
-rw-r----- 1 root root  2097152 2014/12/22 09:13 xtrabackup_logfile

--观察上面文件夹内容的变化,可以看到09:14为新增或发生变化的文件,主要是生成了系统表空间数据文件及innodb日志文件
--同时有关Innodb的检查点文件也进行了更新(注,热备只涉及到InnoDB引擎,所有与InnoDB相关的都会在apply-log时发生变化

--将原有文件夹重命名到新位置,并创建原文件夹
SHELL> mv /data/inst3606/data3606 /data/inst3606/data3606bk
SHELL> mkdir -p /data/inst3606/data3606

--将已经恢复好的数据文件复制回原始位置
SHELL> innobackupex --user=robin -password=xxx --port=3606 --defaults-file=/data/inst3606/data3606bk/my3606.cnf \ 
> --copy-back /data/bak/hotbak/2014-12-22_09-04-05
                    ......非重要信息忽略,下同......
innobackupex: Starting to copy files in '/data/bak/hotbak/2014-12-22_09-04-05' --启动将备份的文件复制回原路径
innobackupex: back to original data directory '/data/inst3606/data3606'        --原路径位置 
                     ............复制所有的数据文件,索引文件个,格式文件等............
innobackupex: Starting to copy InnoDB system tablespace  --复制系统表空间
innobackupex: in '/data/bak/hotbak/2014-12-22_09-04-05'
innobackupex: back to original InnoDB data directory '/data/inst3606/data3606'
innobackupex: Copying '/data/bak/hotbak/2014-12-22_09-04-05/ibdata1' to '/data/inst3606/data3606/ibdata1'

innobackupex: Starting to copy InnoDB undo tablespaces   --复制undo表空间
innobackupex: in '/data/bak/hotbak/2014-12-22_09-04-05'
innobackupex: back to '/data/inst3606/data3606'

innobackupex: Starting to copy InnoDB log files          --复制redo表空间
innobackupex: in '/data/bak/hotbak/2014-12-22_09-04-05'
innobackupex: back to original InnoDB log directory '/data/inst3606/data3606'
innobackupex: Copying '/data/bak/hotbak/2014-12-22_09-04-05/ib_logfile1' to '/data/inst3606/data3606/ib_logfile1'
innobackupex: Copying '/data/bak/hotbak/2014-12-22_09-04-05/ib_logfile0' to '/data/inst3606/data3606/ib_logfile0'
innobackupex: Finished copying back files.

141222 09:34:47  innobackupex: completed OK!

--权限修改
SHELL> cp /data/inst3606/data3606bk/my3606.cnf /data/inst3606/data3606/my3606.cnf
SHELL> chown -R mysql:mysql /data/inst3606/data3606

--启动恢复后的实例
SHELL>  mysqld_safe --defaults-file=/data/inst3606/data3606bk/my3606.cnf &

--验证恢复情况
SHELL>  sql -P3606
robin@localhost[(none)]> select * from fullbakdb.tb;
+------+---------+
| id   | val     |
+------+---------+
|    1 | robin   |
|    2 | leshami |
+------+---------+

robin@localhost[(none)]> drop database fullbakdb;
Query OK, 1 row affected (0.01 sec)

3、小结 a、Xtrabackup恢复的目的要是保证事务(数据)的一致性,Xtrabackup log会记录这些事务备份期间的状态 b、恢复过程分为2个阶段,一个是Prepare阶段,一个是copy back阶段,恢复前关闭原有实例 c、Prepare阶段会根据从innodb logfile捕获出来的信息(记录在xtrabackup log)来进行相应的前滚或回滚 d、Prepare阶段会在成功前滚或回滚后创建新的innodb logfile(空) e、copy back阶段则是将成功恢复的全部文件复制回原来或指定的数据目录(目录应为空目录) f、copy back前需要关闭原有实例,如果恢复到不同的实例则不需要 g、copy back完成后应做相应的权限修改 h、启动恢复后的实例并进行相关验证

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

MySQL 传统复制中常见故障处理和结构优化案例分析

虽然MySQL5.7 的主从复制已经很稳定了,但在备库可读写的情况下,总是会出现部分数据不一致的情况,例如常见的1062、1032和1050错误。下面就介绍下这...

3087
来自专栏散尽浮华

分布式监控系统Zabbix3.4-针对MongoDB性能监控操作笔记

公司在IDC机房的一台服务器上部署了MongoDB,由于所存储的业务数据比较重要,所以对MongoDB的监控显得尤为重要!Zabbix监控MongoDB性能的原...

4104
来自专栏张善友的专栏

配置Windows 2008 R2 防火墙允许远程访问SQL Server 2008 R2

1.先修改 sql server 2008R2的端口号吧,1433经常成为别人入侵的端口,在sql server 配置管理器 --》sql server 网络配...

2526
来自专栏王磊的博客

Spring Boot 最佳实践(五)Spring Data JPA 操作 MySQL 8

JPA(Java Persistence API)Java持久化API,是 Java 持久化的标准规范,Hibernate是持久化规范的技术实现,而Spring...

2762
来自专栏SpringBoot 核心技术

第三十九章:基于SpringBoot & Quartz完成定时任务分布式单节点持久化

68810
来自专栏杨建荣的学习笔记

Data Guard高级玩法:通过闪回恢复switchover主库 (r10笔记第13天)

最近又试了下Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的...

3417
来自专栏实战docker

pinpoint插件开发之一:牛刀小试,调整gson插件

从本章开始我们一起来实战pinpoint插件开发,做一些实用的pinpoint插件,本着先易后难的原则,我们从修改现有插件开始吧; 准备工作 本次实战的操作环境...

3485
来自专栏deed博客

交叉编译安卓busybox

1872
来自专栏乐沙弥的世界

MHA 清理relay log(purge_relay_logs)

    MySQL数据库主从复制在缺省情况下从库的relay logs会在SQL线程执行完毕后被自动删除,但是对于MHA场景下,对于某些滞后从库的恢复依赖于其他...

1490
来自专栏黑白安全

JAVA SYSTEM SOLUTIONS SSO PLUGIN FOR BMC MYIT 跨站脚本漏洞

  今天看到这个漏洞,找了一个国外的站复现了一下,并且想出了一个新的思路,分享一下。

1463

扫码关注云+社区

领取腾讯云代金券