innobackup 备份还原原理和操作

 

详细内容参见网址：http://www.jb51.net/article/41570.htm

 

优势：

1、快速可靠的进行完全备份
2、在备份的过程中不会影响到事务
3、支持数据流、网络传输、压缩，所以它可以有效的节约磁盘资源和网络带宽。
4、可以自动备份校验数据的可用性。

安装：

Xtrabackup，查看另外的总结

 

 

4.1前提：（我们用这个工具一般都进行整个服务器的全备份，这步可以先不管。跳过直接进行备份就可以了。）

 

 

这步看之前先知道一些概念：

Innodb和myisam引擎的表与那些文件组成：

Myisqm表：

.frm 表结构文件

.MYI表索引文件

.MYD表数据文件

 

 

Innodb表;

共享表空间存储方式下：

.frm表结构文件

.ibdata所有的innodb表的数据和索引存放的文件

独立表空间存储方式下：

.frm 表结构文件

.ibd各表自己的数据和索引存放文件

 

 

 

 

共享表空间： Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成（具体的表现是数据库目录下会有一个或几个名字是ibdata1，ibdata2，ibdata3...具体多少是可以配置的，默认只有一个ibdata1文件，所有的innodb引擎的表数据和索引都会存到这几个文件中），一个表或多个表可能跨多个文件存在，所以其大小限制不再是文件大小的限 制和单个磁盘的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单表限制基本上也在64TB左右 了，当然这个大小是包括这个表的所有索引等其他相关数据。（这种方式存储磁盘满了，加上一块，之后在新建个，新磁盘/ibdata* 文件就行了-新建的方式就是配置my.cnf文件重启数据库就行。不是特别简单的。具体的加ibdata文件，在本目录下的   ”innodb引擎共享空间存储方式下的ibdata文件扩容.doc”查看详细步骤或网址http://blog.csdn.net/zm2714/article/details/8479974/）

 

独立表空间：每张innodb引擎的表都有自己的.ibd文件。数据和索引都存在这个文件中。这里引申个问题，当单个磁盘空间不足时。只能通过文件系统层面过的方法扩容。这里是用的技术是lvm。具体将会在文档“lvm磁盘扩容-磁盘分区-磁盘挂载卸载-自动挂载.doc”中细总结。

 

 

 

 

应该确定采用的是单表一个表空间，否则不支持单表的备份与恢复。
在配置文件里边的mysqld段加上

innodb_file_per_table = 1

为搞懂，这里停留了很长时间。

这里意思是：这种备份方式支持单表备份和还原，但是前提是必须将配置文件中innodb_file_per_table = 1，设置成1。

---当这个变量设置成1时，所有的innodb引擎的表，在数据库目录中的存储方式将会是‘独立表空间存储方式’——即每个innodb表将会独有一个表空间。具体的表现是每个innodb表在数据库目录下都有个*.ibd的文件，这个文件就是这张表的独立表空间，这张表的所有的数据和索引都会存储在这个文件中。这样以后每次建表时都会是一张表一个.ibd文件，那么就可以做单张的表的备份和恢复。

那这里其实是有问题的，如果我的数据库中已经有很多的数据了，并且之前并不是按照“独立表空间的存储方式存的”而是按照“共享表空间的存储方式存的”，那么这时是不能单单修改了配置文件（innodb_file_per_table = 1）就行----关于共享表空间和独立表空间具体细节参看（http://www.linuxidc.com/Linux/2015-01/111241.htm）。当时作者的意思是刚刚建立数据库时要设置成这样（innodb_file_per_table = 1）。

 

4.2备份策略：

 

完全备份+增量备份+二进制日志

 

 

4.3准备个目录用于存放备份数据

复制代码 代码如下:

[root@www ~]# makdir /innobackup

 

 

4.4做完全备份：

复制代码 代码如下:

[root@www ~]# innobackupex --user=root --password=mypass   /innobackup/

注：

1、只要在最后一行显示 innobackupex: completed OK!，就说明你的备份是正确的。
2、另外要注意的是每次备份之后，会自动在数据目录下创建一个以当前时间点命名的目录用于存放备份的数据，那我们去看看都有什么

[root@www 2013-09-12_11-03-04]# ls
backup-my.cnf ibdata1 performance_schema xtrabackup_binary xtrabackup_checkpoints
hellodb mysql test xtrabackup_binlog_info xtrabackup_logfile
[root@www 2013-09-12_11-03-04]#
xtrabackup_checkpoints ：备份类型、备份状态和LSN(日志序列号)范围信息；
xtrabackup_binlog_info ：mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
xtrabackup_logfile ：非文本文件，xtrabackup自己的日志文件
xtrabackup_binlog_pos_innodb ：二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。
backup-my.cnf ：备份时数据文件中关于mysqld的配置

 

#xtrabackup备份原理：

官方原理

在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动 时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。

 

xtrabackup在启动时会记住log sequence number（LSN），并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。这 时，xtrabackup会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。xtrabackup必须持续的做这个操作，是因为事务日 志是会轮转重复的写入，并且事务日志可以被重用。所以xtrabackup自启动开始，就不停的将事务日志中每个数据文件的修改都记录下来。

 

上面就是xtrabackup的备份过程。接下来是准备（prepare）过程。在这个过程中，xtrabackup使用之前复制的事务日志，对各个数据文件执行灾难恢复（就像MySQL刚启动时要做的一样）。当这个过程结束后，数据库就可以做恢复还原了。

以上的过程在xtrabackup的编译二进制程序中实现。程序innobackupex可以允许我们备份MyISAM表和frm文件从而增加了便捷和功 能。Innobackupex会启动xtrabackup，直到xtrabackup复制数据文件后，然后执行FLUSH TABLES WITH READ LOCK来阻止新的写入进来并把MyISAM表数据刷到硬盘上，之后复制MyISAM数据文件，最后释放锁。

 

备份MyISAM和InnoDB表最终会处于一致，在准备（prepare）过程结束后，InnoDB表数据已经前滚到整个备份结束的点，而不是回滚到 xtrabackup刚开始时的点。这个时间点与执行FLUSH TABLES WITH READ LOCK的时间点相同，所以MyISAM表数据与InnoDB表数据是同步的。类似Oracle的，InnoDB的prepare过程可以称为recover（恢复），MyISAM的数据复制过程可以称为restore（还原）。

 

xtrabackup和innobackupex这两个工具都提供了许多前文没有提到的功能特点。手册上有对各个功能都有详细的介绍。简单介绍下，这些工 具提供了如流（streaming）备份，增量（incremental）备份等，通过复制数据文件，复制日志文件和提交日志到数据文件（前滚）实现了各 种复合备份方式。

xtrabackup详细的原理请参见：http://sofar.blog.51cto.com/353572/1313649

 

 

4.5回到mysql服务器端对数据进行更新操作

复制代码 代码如下:

mysql> use hellodb;
mysql> delete from students where StuID>=24;

4.6增量备份

复制代码 代码如下:

innobackupex --user=root --password=mypass --incremental /innobackup/--incremental-basedir=/innobackup/2013-09-12_11-03-04/
--incremental  指定备份类型
--incremental-basedir= 指定这次增量备份是基于哪一次备份的，这里是完全备份文件,这样可以把增量备份的数据合并到完全备份中去

“--incremental-basedir”这个参数名字变了运行innobackupex --help查看

 

4.7第二次增量

先去修改数据

复制代码 代码如下:

mysql> insert into students (Name,Age,Gender,ClassID,TeacherID) values ('tom',33,'M',2,4);
innobackupex --user=root --password=mypass --incremental /innobackup/ --incremental-basedir=/innobackup/2013-09-12_11-37-01/
 这里只须要把最后的目录改为第一次增量备份的数据目录即可

“--incremental-basedir”这个参数名字变了运行innobackupex --help查看

 

4.8最后一次对数据更改但是没做增量备份

复制代码 代码如下:

mysql> delete from coc where id=14;

4.9把二进制日志文件备份出来，(因为最后一次修改，没做增量备份，要依赖二进制日志做时间点恢复)

复制代码 代码如下:

[root@www data]# cp mysql-bin.000003 /tmp/

 

 

4.10模拟数据库崩溃

复制代码 代码如下:

[root@www data]# service mysqld stop
[root@www data]# rm -rf *

恢复前准备：重点这个必须有

4.11对完全备份做数据同步

复制代码 代码如下:

[root@www ~]# innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/

4.12对第一次增量做数据同步

复制代码 代码如下:

innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/ --incremental-basedir=/innobackup/2013-09-12_11-37-01/

 

“--incremental-basedir”这个参数名字变了运行innobackupex --help查看

 

4.13对第二次增量做数据同步

复制代码 代码如下:

innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/ --incremental-basedir=/innobackup/2013-09-12_11-45-53/
--apply-log 的意义在于把备份时没commit的事务撤销，已经commit的但还在事务日志中的应用到数据库

“--incremental-basedir”这个参数名字变了运行innobackupex --help查看

 

 

 

 

 

 

###############################################

注：

对于xtrabackup来讲，它是基于事务日志和数据文件备份的，备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据库文件中的事务，还应该对其做预处理，把已提交的事务同步到数据文件，未提交的事务要回滚。因此其备份的数据库，不能立即拿来恢复。

预处理的过程：

首先对完全备份文件只把已提交的事务同步至数据文件，要注意的是有增量的时候，不能对事务做数据回滚，不然你的增量备份就没有效果了。

然后把第一次的增量备份合并到完全备份文件内，

以此类推，把后几次的增量都合并到前一次合并之后的文件中，这样的话，我们只要拿着完全备份+二进制日志，就可以做时间点恢复。

 

 

 

 

 

为什么要恢复前准备：xtrabackup 在启动时会记住log sequence number（LSN），并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。这 时，xtrabackup会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。

 

备 份MyISAM和InnoDB表最终会处于一致，在准备（prepare）过程结束后，InnoDB表数据已经前滚到整个备份结束的点，而不是回滚到 xtrabackup刚开始时的点。这个时间点与执行FLUSH TABLES WITH READ LOCK的时间点相同，所以MyISAM表数据与InnoDB表数据是同步的。类似Oracle的，InnoDB的prepare过程可以称为recover（恢复），MyISAM的数据复制过程可以称为restore（还原）。

 

个人理解：备份完成时，备份的数据是备份开始时间点的样子，在备份过程中数据的变化会记录到事务日志中。因此你备份的数据库不能直接使用必须要recover（恢复），恢复完成之后那么备份的数据库的状态就是你备份结束时的样子。备份结束后的数据改变就只能指望二进制文件了。所以还要把当时的那个二进制文件拷贝出来，用于进行精确地时间恢复。或者位置恢复。

 

 

 

 

 

4.14数据恢复

复制代码 代码如下:

[root@www ~]# service mysqld stop
[root@www data]# rm -rf *  模拟数据库崩溃
[root@www ~]# innobackupex --copy-back /innobackup/2013-09-12_11-03-04/
--copy-back数据库恢复，后面跟上备份目录的位置

 

 

 

 

 

 

4.15检测：

复制代码 代码如下:

[root@www ~]# cd /mydata/data/
[root@www data]# chown mysql:mysql *
[root@www data]#service mysqld start

 

注：必须更改好数据目录下所有文件的属主和属组，否则无法启动。

 

 

前边就完成了完全备份和恢复，但之前那个二进制文件文件怎么办，干什么用。做基于时间点的恢复。详细使用请参见：

http://blog.sina.com.cn/s/blog_62a24b6801013vcy.html

 

 

mysqlbinlog --stop-date="2009-09-01 00:00:00" /mysqldata/mysql-bin.000009 | mysql -u root -p

 

 

 

 

 

 

 

 

 

 

 

 

 

参考过程：

一、全部数据库

 

备份：

 

innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf /data/mysql_backup/full_backup

 

 

 二、指定数据库

 

备份:

 

假如我们要备份centos和aabb数据库。

 

innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf --databases="centos aabb" /data/mysql_backup/

 

这样就会在/data/mysql_backup生成一个带时间的目录，如果不需要带时间，可以使用选项–no-timestamp。

 

如果想备份成压缩文件，可以使用如下语句：

 

innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf --databases="centos aabb" --no-timestamp --stream=tar ./ | gzip - > centos-aabb.bz.tar.gz

 

 

 

innobackupex  --defaults-file=/etc/my.cnf --user=root --host=127.0.0.1 --password=''  --databases="lidonghai mysql" --slave-info --safe-slave-backup --stream=tar /data/innobackup/ > /data/innobackup/test.tar.gz

参数：

--slave-info这个参数在对从数据库进行备份时使用，可以保存主数据库当前的二进制文件和偏移量。这样可以减轻主数据库因备份二压力过大。其他参数自行查看。需要注意的是，你的数据库超时设定会对备份有影响。在备份结束的时候快要结束的时候，有时候可能会因为你的数据库连接超时而中断，造成备份失败。所以把数据库超时设定加大才好，不要过短。

 

 

 

 

 

innobackupex  --defaults-file=/data/mysql/my.cnf --user=root --host=172.168.1.51 --password=horizoompassword   --slave-info --safe-slave-backup --stream=tar /data/innobackup/ > /data/innobackup/fullbackup.tar.gz

 

tar -ixf test.tar.gz -C /data/innobackup/test

 

 

innobackupex --apply-log --redo-only /data/innobackup/test

 

innobackupex --copy-back /data/innobackup/test  --user=root --host=127.0.0.1 --password=''  #--force-non-empty-directories这个选项失败了不知道怎么回事，可以的话已更改能部分恢复数据库。最后我手动将目录拷回来改了权限就行了，当人如果不行的话就直单个表单个表的回复。

所以尽量用完全备份。

 

 

 

4.14数据恢复

 

注意：需要指定配置文件，否则找不到要还原的目录

复制代码 代码如下:

 

[root@www ~]# service mysqld stop

[root@www data]# rm -rf *  模拟数据库崩溃

[root@www ~]# innobackupex --defaults-file=/usr/my.cnf --copy-back /innobackup/2013-09-12_11-03-04/

--copy-back数据库恢复，后面跟上备份目录的位置

 

 

 

 

 

 

4.15检测：

复制代码 代码如下:

 

[root@www ~]# cd /mydata/data/

[root@www data]# chown mysql:mysql *

[root@www data]#service mysqld start

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

##################################################

基于完全备份后的单表恢复，这种恢复方式前提是问题表没有被重建过

参看网址：http://www.zhongweicheng.com/?p=1284

 

 

 

MySQL innobackupex全备中恢复Innodb单表

First, you must meet certain prerequisites to be able to restore a ibd tablespace:
1.The ibd file must be from a consistent backup with all insert buffer entries merged  and have no uncommitted transactions in order to not be dependent of the shared 2.tablespace ibdata. That is, shutting down with innodb_fast_shutdown=0. We’ll use XtraBackup to avoid the server shutdown.
3.You must not drop, truncate or alter the schema of the table after the backup has been taken.
The variable innodb_file_per_table must be enabled.
[root@test bin]# ./innobackupex –defaults-file=/service/mysql5.5/my.cnf  –export /backup/5.5/  
  
  
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy  
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.  
  
  
This software is published under  
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.  
  
  
131125 19:50:23  innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_file=/service/mysql5.5/my.cnf;mysql_read_default_group=xtrabackup' (using password: NO).  
131125 19:50:23  innobackupex: Connected to MySQL server  
IMPORTANT: Please check that the backup run completes successfully.  
           At the end of a successful backup run innobackupex  
           prints "completed OK!".  
  

  
innobackupex: Using mysql server version 5.5.25-log  
  
  
innobackupex: Created backup directory /backup/5.5/2013-11-25_19-50-23  
  
  
131125 19:50:23  innobackupex: Starting ibbackup with command: xtrabackup_55  –defaults-file="/service/mysql5.5/my.cnf"  –defaults-group="mysqld" –backup –suspend-at-end –target-dir=/backup/5.5/2013-11-25_19-50-23 –tmpdir=/tmp  
innobackupex: Waiting for ibbackup (pid=13361) to suspend  
innobackupex: Suspend file '/backup/5.5/2013-11-25_19-50-23/xtrabackup_suspended_2'  
  
  
xtrabackup_55 version 2.1.5 for Percona Server 5.5.31 Linux (x86_64) (revision id: 680)  
xtrabackup: uses posix_fadvise().  
xtrabackup: cd to /data/mysql5.5  
xtrabackup: using the following InnoDB configuration:  
xtrabackup:   innodb_data_home_dir = ./  
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend  
xtrabackup:   innodb_log_group_home_dir = ./  
xtrabackup:   innodb_log_files_in_group = 3  
xtrabackup:   innodb_log_file_size = 5242880  
>> log scanned up to (1600610)  
[01] Copying ./ibdata1 to /backup/5.5/2013-11-25_19-50-23/ibdata1  
[01]        …done  
[01] Copying ./test/t2.ibd to /backup/5.5/2013-11-25_19-50-23/test/t2.ibd  
[01]        …done  
>> log scanned up to (1600610)  
xtrabackup: Creating suspend file '/backup/5.5/2013-11-25_19-50-23/xtrabackup_suspended_2' with pid '13361'  
  
  
131125 19:50:25  innobackupex: Continuing after ibbackup has suspended  
131125 19:50:25  innobackupex: Starting to lock all tables…  
131125 19:50:25  innobackupex: All tables locked and flushed to disk  
  
  
131125 19:50:25  innobackupex: Starting to backup non-InnoDB tables and files  
innobackupex: in subdirectories of '/data/mysql5.5'  
innobackupex: Backing up file '/data/mysql5.5/test/t2.frm'  
innobackupex: Backing up files '/data/mysql5.5/mysql/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files)  
>> log scanned up to (1600610)  
innobackupex: Backing up files '/data/mysql5.5/performance_schema/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files)  
131125 19:50:26  innobackupex: Finished backing up non-InnoDB tables and files  
  
  
131125 19:50:26  innobackupex: Waiting for log copying to finish  
  
  
xtrabackup: The latest check point (for incremental): '1600610'  
xtrabackup: Stopping log copying thread.  
.>> log scanned up to (1600610)  
  
  
xtrabackup: Creating suspend file '/backup/5.5/2013-11-25_19-50-23/xtrabackup_log_copied' with pid '13361'  
xtrabackup: Transaction log of lsn (1600610) to (1600610) was copied.  
131125 19:50:27  innobackupex: All tables unlocked  
  
  
innobackupex: Backup created in directory '/backup/5.5/2013-11-25_19-50-23'  
innobackupex: MySQL binlog position: filename 'ZWC-TEST.000003', position 420  
131125 19:50:27  innobackupex: Connection to database server closed  
131125 19:50:27  innobackupex: completed OK!   

 

Truncate t2 table
root@test 07:52:19>show create table t2\G  
*************************** 1. row ***************************  
       Table: t2  
Create Table: CREATE TABLE `t2` (  
  `id` int(11) NOT NULL,  
  `name` varchar(10) DEFAULT NULL,  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB DEFAULT CHARSET=utf8  
1 row in set (0.00 sec)  
  
root@test 07:52:28>select count(*) from t2;  
+———-+  
| count(*) |  
+———-+  
|        2 |  
+———-+  
1 row in set (0.00 sec)  
  
root@test 07:52:36>alter table t2 discard tablespace;  
Query OK, 0 rows affected (0.00 sec)  
  
root@test 07:52:46>select count(*) from t2;  
ERROR 1030 (HY000): Got error -1 from storage engine   

 

Begin recovery t2
Then apply the logs to get a consistent backup.
[root@test bin]# ./innobackupex –defaults-file=/service/mysql5.5/my.cnf –apply-log  –export /backup/5.5/2013-11-25_19-50-23/  
  
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy  
and Percona LLC and/or its affiliates 2009-2013.  All Rights Reserved.  
  
This software is published under  
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.  
  
IMPORTANT: Please check that the apply-log run completes successfully.  
           At the end of a successful apply-log run innobackupex  
           prints "completed OK!".  
  
  
  
131125 19:53:30  innobackupex: Starting ibbackup with command: xtrabackup_55  –defaults-file="/service/mysql5.5/my.cnf"  –defaults-group="mysqld" –prepare –target-dir=/backup/5.5/2013-11-25_19-50-23 –export –tmpdir=/tmp  
  
xtrabackup_55 version 2.1.5 for Percona Server 5.5.31 Linux (x86_64) (revision id: 680)  
xtrabackup: cd to /backup/5.5/2013-11-25_19-50-23  
xtrabackup: This target seems to be not prepared yet.  
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1600610)  
xtrabackup: using the following InnoDB configuration for recovery:  
xtrabackup:   innodb_data_home_dir = ./  
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend  
xtrabackup:   innodb_log_group_home_dir = ./  
xtrabackup:   innodb_log_files_in_group = 1  
xtrabackup:   innodb_log_file_size = 2097152  
xtrabackup: using the following InnoDB configuration for recovery:  
xtrabackup:   innodb_data_home_dir = ./  
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend  
xtrabackup:   innodb_log_group_home_dir = ./  
xtrabackup:   innodb_log_files_in_group = 1  
xtrabackup:   innodb_log_file_size = 2097152  
xtrabackup: Starting InnoDB instance for recovery.  
xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory parameter)  
131125 19:53:30 InnoDB: The InnoDB memory heap is disabled  
131125 19:53:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins  
131125 19:53:30 InnoDB: Compressed tables use zlib 1.2.3  
131125 19:53:30 InnoDB: Initializing buffer pool, size = 100.0M  
131125 19:53:30 InnoDB: Completed initialization of buffer pool  
131125 19:53:30 InnoDB: highest supported file format is Barracuda.  
InnoDB: The log sequence number in ibdata files does not match  
InnoDB: the log sequence number in the ib_logfiles!  
131125 19:53:30  InnoDB: Database was not shut down normally!  
InnoDB: Starting crash recovery.  
InnoDB: Reading tablespace information from the .ibd files…  
InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003  
131125 19:53:30  InnoDB: Waiting for the background threads to start  
131125 19:53:31 Percona XtraDB (http://www.percona.com) 5.5.31-29.3 started; log sequence number 1600610  
xtrabackup: export option is specified.  
xtrabackup: export metadata of table 'test/t2' to file `./test/t2.exp` (1 indexes)  
xtrabackup:     name=PRIMARY, id.low=15, page=3  
  
[notice (again)]  
  If you use binary log and don't use any hack of group commit,  
  the binary log position seems to be:  
InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003  
  
xtrabackup: starting shutdown with innodb_fast_shutdown = 0  
131125 19:53:31  InnoDB: Starting shutdown…  
131125 19:53:35  InnoDB: Shutdown completed; log sequence number 1601824  
  
131125 19:53:35  innobackupex: Restarting xtrabackup with command: xtrabackup_55  –defaults-file="/service/mysql5.5/my.cnf"  –defaults-group="mysqld" –prepare –target-dir=/backup/5.5/2013-11-25_19-50-23 –export –tmpdir=/tmp  
for creating ib_logfile*  
  
xtrabackup_55 version 2.1.5 for Percona Server 5.5.31 Linux (x86_64) (revision id: 680)  
xtrabackup: cd to /backup/5.5/2013-11-25_19-50-23  
xtrabackup: This target seems to be already prepared.  
xtrabackup: notice: xtrabackup_logfile was already used to '–prepare'.  
xtrabackup: using the following InnoDB configuration for recovery:  
xtrabackup:   innodb_data_home_dir = ./  
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend  
xtrabackup:   innodb_log_group_home_dir = ./  
xtrabackup:   innodb_log_files_in_group = 3  
xtrabackup:   innodb_log_file_size = 5242880  
xtrabackup: using the following InnoDB configuration for recovery:  
xtrabackup:   innodb_data_home_dir = ./  
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend  
xtrabackup:   innodb_log_group_home_dir = ./  
xtrabackup:   innodb_log_files_in_group = 3  
xtrabackup:   innodb_log_file_size = 5242880  
xtrabackup: Starting InnoDB instance for recovery.  
xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory parameter)  
131125 19:53:35 InnoDB: The InnoDB memory heap is disabled  
131125 19:53:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins  
131125 19:53:35 InnoDB: Compressed tables use zlib 1.2.3  
131125 19:53:35 InnoDB: Initializing buffer pool, size = 100.0M  
131125 19:53:35 InnoDB: Completed initialization of buffer pool  
131125 19:53:35  InnoDB: Log file ./ib_logfile0 did not exist: new to be created  
InnoDB: Setting log file ./ib_logfile0 size to 5 MB  
InnoDB: Database physically writes the file full: wait…  
131125 19:53:35  InnoDB: Log file ./ib_logfile1 did not exist: new to be created  
InnoDB: Setting log file ./ib_logfile1 size to 5 MB  
InnoDB: Database physically writes the file full: wait…  
131125 19:53:35  InnoDB: Log file ./ib_logfile2 did not exist: new to be created  
InnoDB: Setting log file ./ib_logfile2 size to 5 MB  
InnoDB: Database physically writes the file full: wait…  
131125 19:53:35 InnoDB: highest supported file format is Barracuda.  
InnoDB: The log sequence number in ibdata files does not match  
InnoDB: the log sequence number in the ib_logfiles!  
131125 19:53:35  InnoDB: Database was not shut down normally!  
InnoDB: Starting crash recovery.  
InnoDB: Reading tablespace information from the .ibd files…  
InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003  
131125 19:53:35  InnoDB: Waiting for the background threads to start  
131125 19:53:36 Percona XtraDB (http://www.percona.com) 5.5.31-29.3 started; log sequence number 1602060  
xtrabackup: export option is specified.  
xtrabackup: export metadata of table 'test/t2' to file `./test/t2.exp` (1 indexes)  
xtrabackup:     name=PRIMARY, id.low=15, page=3  
  
[notice (again)]  
  If you use binary log and don't use any hack of group commit,  
  the binary log position seems to be:  
InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003  
  
xtrabackup: starting shutdown with innodb_fast_shutdown = 0  
131125 19:53:36  InnoDB: Starting shutdown…  
131125 19:53:40  InnoDB: Shutdown completed; log sequence number 1602060  
131125 19:53:40  innobackupex: completed OK!   

 

Copy the t2.ibd files from the backup to the database data directory
[root@test bin]# cp /backup/5.5/2013-11-25_19-50-23/test/t2.ibd /data/mysql5.5/test/  
[root@test bin]# chown mysql.mysql /data/mysql5.5/test/t2.ibd    

 

Import tablespace.
root@test 07:55:55>select count(*) from t2;  
ERROR 1030 (HY000): Got error -1 from storage engine  
root@test 07:55:56>  
root@test 07:55:56>  
root@test 07:55:57>alter table t2 import tablespace;  
Query OK, 0 rows affected (0.00 sec)  
  
root@test 07:56:04>select count(*) from t2;  
+———-+  
| count(*) |  
+———-+  
|        2 |  
+———-+  
1 row in set (0.00 sec)  
  
root@test 07:56:08>select * from t2;  
+—-+——+  
| id | name |  
+—-+——+  
|  1 | aaa  |  
|  2 | bbb  |  
+—-+——+  
2 rows in set (0.00 sec)  
  
root@test 07:56:13>  

 

 

 

 

流备份和压缩

提到流备份(streaming)就要说远程备份和备份压缩，先说流备份吧。

流备份是指备份的数据通过标准输出STDOUT传输给tar程序进行归档，而不是单纯的将数据文件保存到指定的备份目录中，参数--stream=tar表示开启流备份功能并打包。同时也可以利用流备份到远程服务器上。

举例来说，

$ innobackupex --stream=TAR ${BACKUP_DIR}/base | gzip > ${BACKUP_DIR}/base.tar.gz $ innobackupex --stream=TAR ${BACKUP_DIR}/base|ssh somebackupaddr “cat > ${DIR}/base.tar”

 

在我们现实使用中，更多的使用增量备份，至于归档压缩我们可以通过脚本自主完成。

 

基于单表备份的单表恢复（这里可有流备份），前提也是问题表没有被重新建立过。否则是不会成功的。

 

 

建好备份目录；mkdir /data/backup -p

 

压缩备份：

innobackupex --user=root --password=simlinux.com   --defaults-file=/etc/my.cnf --include='se.searchaccount' --slave-info --safe-slave-backup --stream=tar /data/backup > /data/backup/searchaccount.tar.gz

 

 

 

参数：--safe-slave-backup 备份slave:

 

                      Stop slave SQL thread and wait to start backup until

                      Slave_open_temp_tables in "SHOW STATUS" is zero. If there

                      are no open temporary tables, the backup will take place,

                      otherwise the SQL thread will be started and stopped

                      until there are no open temporary tables. The backup will

                      fail if Slave_open_temp_tables does not become zero after

                      --safe-slave-backup-timeout seconds. The slave SQL thread

                      will be restarted when the backup finishes.

 

 

 

新建个目录-mkdir /data/databak;

 

解压备份到干净的目录：

tar -ixf searchaccount.tar.gz -C /data/databak/

 

 

导出表:innobackupex --apply-log --export /data/databak

 

查看下： ll /data/databak/se

里边的.ibd文件是我们需要的。

 

 

模拟原来的数据表损坏：

mysql > ALTER TABLE se.searchaccount DISCARD TABLESPACE;

拷贝要恢复的表的.ibd文件到数据库目录下：

cp /data/databak/se/{searchaccount.ibd,searchaccount.cfg} /usr/local/mysql/data

 

 

 

改变拷贝过去的.ibd文件的属主和属组：

chown mysql.mysql ...ibd文件。必须改。

 

 

导入表：强调下这个问题表没有被重新建立过才会成功

 

ALTER TABLE se.searchaccount IMPORT TABLESPACE;

 

 

 

 

#######################################

 

如果问题表是被误删除的那么恢复的时候是有点复杂的，不管是从完全备份那里恢复还是从单表备份哪里恢复，都是一样的。

 

 

如果问题表被删除了，那么与上边的恢复差别就是在最后导入表的部分。

表被删除了的话，恢复是需要修复数据库目录下的ibdata1文件的。

 

修复工具是需要安装的，工具下载地址：https://launchpad.net/percona-data-recovery-tool-for-innodb/+download

 

一.安装：
.tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz
.cd percona-data-recovery-tool-for-innodb-0/mysql-source/
../configure
.cd percona-data-recovery-tool-for-innodb-0
.make

 

 

 

 

具体的操作步骤参见：

http://www.educity.cn/shujuku/692845.html

 

http://www.jb51.net/article/31877.htm

 

 

 

下面的两步相当于上面那些恢复方式的最后一步“导入表”--替换下就可以了

使用percona recovery tool 修改ibdata：(我感觉这里并不是修改ibdata，而是通过ibdata1和A.ibd文件来恢复A表原来的数据。)

./ibdconnect  -o /var/lib/mysql/ibdata1  -f /var/lib/mysql/test/A.ibd -d test -t A

 

使用percona recovery tool 重新checksum ibdata。这一步需要多次执行直到没有输出信息为止。（这里是将事务日志文件中还没有提交的事务redo到硬盘数据页中。因为内存中的脏页由于之前的故障不可用了（本来应该由chakpoint机制来将内存缓冲区的脏页数据刷新到硬盘中的）。）

./innochecksum -f /var/lib/mysql/ibdata1

 

 

 

#####################################################

 

 

 下边是扩展：在没有备份和二进制日志未开启时，若某个表的重要数据被删除后的恢复方式。没测试过不过看最后的注释。这种方法只适用于innodb表，并且最重要的是，一旦数据表中数据被误删除，必须马上停止对这张表的写入操作，否则真的就不能再恢复了。

 

 

使用Percona Data Recovery Tool for InnoDB恢复数据

August 29th, 2013 hidba 

昨晚收到一则求助，一个用户的本地数据库的重要数据由于误操作被删除，需要进行紧急恢复，用户的数据库日常并没有进行过任何备份，binlog也没有开启，所以从备份和binlog入手已经成为不可能，咨询了丁奇，发了一篇percona的文章给我，顿时感觉有希望，于是到percona的官网上下载了恢复工具：
一.安装：
.tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz
.cd percona-data-recovery-tool-for-innodb-0/mysql-source/
../configure
.cd percona-data-recovery-tool-for-innodb-0
.make

二.解析ibd文件：
此过程会将表的idb文件解析为很多的page，innodb的page分为两大部分，一部分一级索引部分（primary key），另一部分为二级索引部分（secondary key），所以解析出来的idb包括了主键数据和索引数据两大部分（如果该表有多个二级索引，则会生成多个文件）
./page_parser -5 -f t_bibasic_storage.ibd
参数解释：
-5：代表 row format为Compact
-f：代表要解析的文件
结果如下：
pages-1377707810/FIL_PAGE_INDEX
0-161 0-325 0-463 0-464 0-465
可以看到t_bibasic_storage.ibd解析出来5个文件（161为主键索引的index_id,325,463,464,465为二级索引的index_id,该id可以通过开启innodb_table_monitor知晓）

三.生成表定义：
由于该工具在解析数据pages的时候，需要获得该table的表结构定义，所以需要执行如下命令：
./create_defs.pl –host xxxx –port 3306 –user root –password xxx –db didb –table t_bibasic_storage >include/table_defs.h
上面的命令会将t_bibasic_storage表的表结构定义传入到table_defs.h中，在生成了表结构定义后，重新make该恢复工具：
.make

四.开始恢复pages中删除的数据：
在重新编译工具后，执行如下命令：
./constraints_parser -5 -D -f pages-1377707810/FIL_PAGE_INDEX/0-161 >/tmp/t_bibasic_salessend.sql
参数：
-5 -f的参数和page_parser相同；
-D:该参数的含义为代表恢复删除的数据页；

恢复完成后生成如下语句和文件：
LOAD DATA INFILE ‘/tmp/t_bibasic_proinfo.dmp’ REPLACE INTO TABLE `t_bibasic_proinfo` FIELDS TERMINATED BY ‘\t’ OPTIONALLY ENCLOSED BY ‘”‘ LINES STARTING BY ‘t_bibasic_proinfo\t’ (id, procode, skuoid, skucode, skuname, catatt, dutydepoid, dutydepname, seasonatt, brandatt, prostatus, choosedate, syear, smonth, sday, created, unioncomcode);

/tmp/t_bibasic_salessend.sql 该文件就是我们需要load data的文本文件；

总结：
1）。该恢复工具只支持innodb存储引擎，文件的格式需要为：Compact
2）。数据被误删除后，需要尽快将保护现场，停止数据库，把idb文件拷贝出来，防止ibd文件写入数据被覆盖（笔者恢复的一个表中，由于数据删除后，表中仍有大量写入，导致大部分数据没有恢复出来）；
3）。千叮嘱万嘱咐，数据库的备份重于泰山；