MySQL社区

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
查看: 3225|回复: 0

[XtraBackup] 使用Percona XtraBackup热备和恢复MySQL

[复制链接]
发表于 2015-10-22 18:21:59 | 显示全部楼层 |阅读模式
1. 在http://www.percona.com/downloads/XtraBackup/LATEST/  下载对应平台的XtraBackup,这里使用的是 http://www.percona.com/redir/dow ... backup-2.0.0.tar.gz

2. 解压tar -zvxf percona-xtrabackup-2.0.0.tar.gz -C /usr/local/

3. 因为MySQL我安装的是Percona-Server-5.5.21,而且安装目录为:/usr/local/Percona-Server-5.5.21-rel25.0-227.Linux.x86_64/,注:同样可以用于其他MySQL版本

cd /usr/local/percona-xtrabackup-2.0.0/bin  
cp * /usr/local/Percona-Server-5.5.21-rel25.0-227.Linux.x86_64/bin/  

因为系统Path里面已经加入

export PATH=$JAVA_HOME/bin:/usr/local/Percona-Server-5.5.21-rel25.0-227.Linux.x86_64/binPATH  

4. 我的mysql的配置文件是/etc/my.cnf,如果不指定,XtraBackup默认使用此文件识别mysql安装目录,数据文件目录等信息

5. 全量备份:innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/,我使用/data/backup/mysql/作为mysql备份文件存放目录

innobackupex --user=YOUS --password=YOUS /data/backup/mysql  


看到类似输出说明备份成功,如出错,根据提示解决

innobackupex: Backup created in directory '/data/backup/mysql/2012-05-28_19-01-32'  
innobackupex: MySQL binlog position: filename 'mysql-bin.000063', position 44718229367  
120528 19:07:53  innobackupex: completed OK!  


可以在/data/backup/mysql/2012-05-28_19-01-32看到备份的文件
此时,cat xtrabackup_checkpoints会看到

backup_type = full-backuped  
from_lsn = 0  
to_lsn = 44718229367  
last_lsn = 44718229367  


6. 全量Preparing:innobackupex --apply-log /path/to/BACKUP-DIR

innobackupex --user=YOUS --password=YOUS --apply-log /data/backup/mysql/2012-05-28_19-01-32/  

可以看到如下生成文件:

-rw-r--r--. 1 root root          13 May 28 19:07 xtrabackup_binary  
-rw-r--r--. 1 root root          26 May 29 15:07 xtrabackup_binlog_info  
-rw-r--r--. 1 root root          43 May 29 15:07 xtrabackup_binlog_pos_innodb  
-rw-r-----. 1 root root          85 May 29 15:07 xtrabackup_checkpoints  
-rw-r-----. 1 root root     2097152 May 29 14:03 xtrabackup_logfile  


cat xtrabackup_checkpoints,可以看出是全量备份并且做了prepare的

backup_type = full-prepared  
from_lsn = 0  
to_lsn = 49556823920  
last_lsn = 49556823920  

7. 增量备份的前提是必须已经做过全量备份。
增量备份:innobackupex --incremental /path/to/BACKUP-DIR/--incremental-basedir=BASEDIR,当有了INCREMENTAL-DIR-1之后,下一次增量备份的需要基于INCREMENTAL-DIR-1,变成innobackupex --incremental /path/to/BACKUP-DIR/ --incremental-basedir=INCREMENTAL-DIR-1
全量备份的目录是:/data/backup/mysql/2012-05-28_19-01-32

innobackupex --incremental /data/backup/mysql --incremental-basedir=/data/backup/mysql/2012-05-28_19-01-32/ --user=YOUS --password=YOUS  

增量备份成功会生成目录/data/backup/mysql/2012-05-29_14-25-03
cat xtrabackup_checkpoints

backup_type = incremental  
from_lsn = 44718229367  
to_lsn = 49556823920  
last_lsn = 49556823920  

8. 增量Preparing,对每一个增量备份目录:
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2

innobackupex --apply-log --redo-only /data/backup/mysql/2012-05-28_19-01-32/ --incremental-dir=/data/backup/mysql/2012-05-29_14-25-03 --user=YOUS--password=YOUS  


看到如下输出:

120529 14:29:43 InnoDB: Shutdown completed; log sequence number 49556823920  
120529 14:29:43 innobackupex: completed OK!  


cd BASE-DIR,cat xtrabackup_checkpoints

backup_type = full-prepared  
from_lsn = 0  
to_lsn = 49556823920  
last_lsn = 49556823920  


当把所有的增量备份都执行Preparing后,还可以全量备份和全部的增量备份做一次Preparing,
innobackupex --apply-log BASE-DIR

9. 恢复数据:innobackupex --copy-back BASE-DIR



在这里恢复innodb数据库时写的很简单,但是在实践的时候发现有报错,类似如下:

IMPORTANT: Please check that the copy-back run completes successfully.  
           At the end of a successful copy-back run innobackupex-1.6.4  
           prints "completed OK!".  
  
Original data directory is not empty! at innobackupex-1.6.4 line 544.  

意思大概是说原始的数据目录不是空的。

谷歌找了一下原因,参见:http://www.mysqlperformanceblog. ... a-xtrabackup-1-6-4/

上面说:

innobackupex did not check that MySQL datadir was empty before –copy-back was run.   
With this bug fix, innobackupex will now error out of the –copy-back operation if the destination is not empty,   
avoiding potential data loss or a strang combination of a restored backup and previous data. Bug Fixed: #737569  
(Valentine Gostev)  

于是找到了这个bug:https://bugs.launchpad.net/percona-xtrabackup/+bug/737569

我用的是percona-xtrabackup-2.0.0,按说这个版本应该解决了这个问题!否则percona也太不厚道了。

所以Original data directory is not empty应该是正常的!可以把Preparing之后的ibdata1和ib_logfile*文件分别复制到mysql的my.cnf里面配置的innodb_data_home_dir目录和datadir目录,然后启动mysql即可!

在这个bug页面的最下面看到以下内容:

Hello,  
  
partial backup restore is not supported. If you have innodb_file_per_table enabled for tables in these databases - you might want to use --export option to restore data from backup partially.  

这里提供了一种partial backup restore的方法。

倒数第二个评论中也提供了怎么部分恢复多个数据库中的若干个的方案。

So, in my understanding, the workround should be: Make sure "ls /var/lib/mysql/mydb01" shows an empty directory OR not existing before running innobackupex --copy-back  

继续找了一下innodb_file_per_table 参数的含义:
InnoDB引擎默认将所有的数据库的表数据存储在一个共享空间中:ibdata1。(这就是为什么我测试写入的时候,这个文件的大小高达37G,而且在drop数据库之后,ibdata1文件不会自动收缩)
这样单个数据库或表的备份成为问题,通常只能将数据使用mysqldump导出,然后再导入解决这个问题。
而用XtraBackup的copy-back也只能一个很大的ibdata1文件来恢复数据,而且要求数据目录是空的,只能全库恢复,不能部分恢复!

在MySQL的配置文件[mysqld]部分,增加innodb_file_per_table=1参数。
修改InnoDB为独立表空间模式,使数据库的每个表都生成一个表空间。

innodb_file_per_table的优点:
  1.每个表都有自已独立的表空间(tablespace)。
  2.每个表的数据和索引都会存在自已的表空间中。
  3.可以实现单表在不同的数据库中移动。
  4.空间可以回收(除drop table操作处,表空不能自已回收)
       a)Drop table操作自动回收表空间,如果对于统计分析或是日值表,删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。
       b)对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。
       c)对于使用独立表空间的表,不管怎么删除,表空间的碎片不会太严重的影响性能,而且还有机会处理。

innodb_file_per_table的缺点:
单表增加过大,如超过100个G。

开启innodb_file_per_table的方法:

1.在my.cnf中[mysqld]下设置
innodb_file_per_table=1

2.查看是否开启:
mysql> show variables like ‘%per_table%’;

3.Move table from system tablespace to its own tablespace.
SET GLOBAL innodb_file_per_table=1;
ALTER TABLE table_name ENGINE=InnoDB;

4. Move table from its own tablespace to system tablespace.
SET GLOBAL innodb_file_per_table=0;
ALTER TABLE table_name ENGINE=InnoDB;

操作完成之后ibdata1的大小不会改变,只是数据库数据目录下每个表从以前的一个.frm文件,多了一个同名的.ibd文件。如果想让ibdata1收缩,只能手动mysqldump出所有数据库的数据到sql文件中,删除原来的ibdata1和ib_logfile*,binlog也可以删掉,相当于在一个空的数据库执行mysqldump出的sql文件。这样,ibdata1就会是my.cnf中配置的初始大小而不会增长。


参考:http://www.percona.com/doc/perco ... ackupex_script.html



转载整理自:
http://willvvv.iteye.com/blog/1544043
http://willvvv.iteye.com/blog/1561124

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|申请友链|小黑屋|Archiver|手机版|MySQL社区 ( 京ICP备07012489号   
联系人:周生; 联系电话:13911732319

GMT+8, 2024-3-28 18:45 , Processed in 0.071666 second(s), 30 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表