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    为了加快恢复速度,设置可用内存参数,可以不用