XtraBackup - 爱码网

xtrabackup备份实际上是在线的物理热备,为什么这么说呢,因为实际上他是以拷贝mysql物理文件来备份的方式,只是加入了一些锁和钩子来避免数据缺失,优势当然就是快了,物理拷贝始终是速度最快的备份方式,缺点就是占用空间大. 备份初期会创建一个redo的钩子,让在备份期间产生的数据都能记录下来,而备份数据文件时也会锁一下表,这样数据就会更完整. xtrabackup支持全备和增备,但是我个人不建议用增备,因为增备效果不怎么样,而且直接拷贝binlog其实也挺好用,所以全备+binlog就可以了. xtrabackup是个链向InnoDB API和mysql client API的C程序，其中 InnoDB API提供日志应用，mysql client API面向命令参数和配置文件解析，另外 xtrabackup有2个模式，要么运行在--backup下，要么运行在--prepare下为了兼容InnoDB数据文件格式，xtrabackup 2.1版本目前存在4种独立的可执行程序 xtrabackup，xtrabackup_51，xtrabackup_55，xtrabackup_56,我们应该根据服务器版本选择相应程序，具体参考下表：我们能够像使用任何mysql客户端那样自如地运用xtrabackup 对命令参数指定既能在命令行上指定也能将其配置在my.cnf里的[xtrabackup]模块
backup备份	当选择--backup模式同时，要指定--target-dir来作为备份保存点，如果--target-dir不存在，则会新建一个但是如果备份已经存在且非空，则xtrabackup会报错：error 17, file exists，类似： xtrabackup: Can't create/write to file '/home/mysql/backup/employees/dept_manager.ibd' (Errcode: 17) 另外，如果日志文件没有一同放在--datadir下，则也要另外加进来开始备份的时候，xtrabackup会进入--datadir目录，进行以下2件主要任务： ① 后台启动一个log-copying线程来每秒监控InnoDB日志文件，当发现变化时则复制变化的块到xtrabackup_logfile 这个log-copying是必须的，因为备份可能会进行较长时间，而恢复则需要从开始到备份结束的所有日志条目但当日志量过载导致log-copying承受不了，则xtrabackup便会报错 ② 复制InnoDB数据文件到备份目录，这不是一个简单的物理拷贝，它会像InnoDB一样，读取数据字典，一次复制一页当完成备份时，xtrabackup会停止log-copying线程，在备份目录下创建一个xtrabackup_checkpoints文件这个文件记录了备份的类型，开始和结束的日志***(LSN)
Preparing备份	从备份到恢复会经过3个步骤：backup→prepare→restore 在prepare之前，数据文件是不一致的，因为它们在不同时间点被备份因此，--prepare会使所有数据文件的步调达成一致这个prepare过程你可以在任何机器上运行，没有强制在线上或者备份库上运行你可以把备份复制到闲置的服务器上去运行prepare，以此来降低备份库的压力不过，你必须保证backup和prepare所使用的xtrabackup的版本要一致在prepare过程中，xtrabackup会启动一个内置的改良的InnoDB，运用备份的日志在备份的数据文件上进行崩溃恢复在prepare过程，建议不能因为计划内或计划外将其中断，这会导致数据文件损坏，备份的有效性将不能得到保证
	--defaults-file 备份数据库的配置文件my.cnf的路径 --user=root 备份操作用户名，一般都是root用户,但可以改 --password=$pwdr 备份操作用户名的密码 --host=$hosts 主机ip，本地可以不加,ssh传输,要开放端口 --parallel=4 并行个数，根据主机配置选择合适的，默认是1个，多个可以加快备份速度。 --throttle=400 运行io限制数,一般来说并行能增加速度,但是IO也高,限制能减少影响 --stream=tar 压缩类型，这里选择tar格式，好像也只能是tar --databases 指定备份的数据库和某个库的表,例如这样:--databases="db db.table",不过要注意的是,他依然会把mysql库备份一遍,因为有很多公共信息还是依赖到他. --no-lock 可以在备份非innodb表和frm文件时不锁表，但是master和slave的pos信息就无法记录，因为write_binlog_info和write_slave_info函数只在mysql_lockall函数中调用，而mysql_lockal调用了flush tables with read lock （不适合生产环境） --use-memory preparing 进程可以通过分配更多的内存来提高速度，这取决于系统的可用内存，默认值是100MB。总的来说分配的内存越多越好。如果是从库,还可以加从库参数 --slave-info 备份目录下会多生成一个xtrabackup_slave_info 文件, 这里会保存主日志文件以及偏移, 文件内容类似于:CHANGE MASTER TO MASTER_LOG_FILE='', MASTER_LOG_POS=0
恢复
	--databases 指定还原的数据库和某个库的表 --export 在--apply-log时使用,为每个InnoDB表创建一个以.exp结尾的文件,然后将你需要恢复的表的ibd和exp文件复制到目标机器，在目标机器上执行导入：mysql> create table t() engine=innodb; //此处需要DBA手动创建一个同结构的表或表已存在 mysql> ALTER TABLE t DISCARD TABLESPACE; $ cp t.ibd t.exp ${DATA_DIR}/${DB}/ mysql> ALTER TABLE t IMPORT TABLESPACE;相当于做了一次表空间传输,恢复了单表数据。 --defaults-file=/etc/my.cnf 使用my.cnf文件,把需要恢复的文件恢复到my.cnf指定的位置,必须写在最前面,不然会报错。 --apply-log 应用备份时产生的日志，为整体拷贝恢复做准备 --copy-back 把完整备份文件拷贝到目标目录,由--defaults-file指定的my.cnf决定 --use-memory=4G 为了加快恢复速度,设置可用内存参数,可以不用