- 积分
- 6147
- UID
- 2
- 阅读权限
- 200
- 注册时间
- 2007-3-19
- 精华
- 在线时间
- 小时
- 最后登录
- 1970-1-1
- 职业
- 1
|
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
|
|