#学习目标
一、备份概述
二、mysqldump xtrabakup工具原理
三、xtrabackup工具使用
****
##一、备份概述
#####1、MySQL备份类型：
（1）冷备和热备：数据库需要停机才能备份的是冷备；备份是online进行的不需要停止业务的是热备。热备又分为逻辑备份、物理备份；
（2）逻辑备份的特点：
——基于数据库表中的行，直接抽取库中表的内容到磁盘中的文件
——备份体积小
——备份灵活
（3）物理备份的特点：
——基于数据库page级拷贝，不会操作数据库的逻辑库和表等
——一般是全库级备份，比较笨重
——备份效率高
——备份体积几乎是源库的大小
#####2、MySQL的备份方式：
全量备份、增量备份
##二、mysqldump xtrabakup工具原理
#####1、mysqldump备份原理
（1）是官方提供的一种逻辑备份工具，单进程备份，效率不高；逻辑备份灵活；产生一系列SQL语句，之后重新执行以产生备份的库、表及数据，也可产生CSV/XML等格式的数据；适用于各种引擎的表；
（2）使用mysqldump命令的最小权限：select,show view,trigger,lock tables
（3）mysqldump工作原理：
（3.1）默认不加--single-transaction参数，备份的开始到结束都是lock table状态（保证数据一致性）
（3.2）加上--single-transaction参数，会临时获取一个全局read锁，用于获取一致性快照，然后通过事务中savepoint将数据进行抽取（只针对事务表innodb）
（4）mysqump命令里的重要参数：
#####2、xtrabackup备份原理
（1）xtrabackup是社区版唯一一个基于page级拷贝的online备份工具，主要基于innodb存储引擎灾难恢复的。复制innodb的数据文件，尽管数据文件在内部是非一致性的，但是执行灾难恢复时可以保证这些数据文件是一致且可用的
（2）xtrabackup备份原理的流程图：
Xtrabackup有两个主要的工具：xtrabackup、innobackupex
（1）xtrabackup只能备份InnoDB和XtraDB两种数据表，而不能备份MyISAM数据表；
（2）innobackupex-1.5.1则封装了xtrabackup，是一个脚本封装，所以能同时备份处理innodb和myisam，但在处理myisam时需要加一个读锁
xtrabackup备份原理的文字描述如下：
1、在物理级别热备份主要的一大挑战就是在文件级别数据块不一致。innodb的单个page大小由innodb_page_size 来决定，一般为16K，由4个文件系统4K的块组成。
2、由于是热备份，当备份工具在拷贝innodb page的时候，数据库本身的进程也有可能在写这个page
那么备份工具拷贝出来的page,就有可能是坏的,也称为page 头尾不一致或是page断裂。这也就是普通的os复制工具（例如cp命令）不能用来做为数据库物理热备份的工具原因。
3、xtrbackup工具备份过程如下：
（1）在备份开始的时候，xtrabackup会像普通的拷贝工具一样去复制所有的innodb page,所以也会有page断裂的问题存在。
（2）xtrabackup在备份开始的时候，生成另一个线程去拷贝当前的innodb的事务日志， 并同时监控innodb的事务日志文件，一旦有生成新的innodb的事务日志，也会同时写到xtrabckup自己的日志中去。
（3）在备份结束后，xtrabacup得到的结果是一份有page断裂的数据文件和备份期间所有的innodb的事务日志。 这个时候的情况和mysql实例崩溃的结果是一样的(实例崩溃后数据文件不完整，事务日志完整)，xtrabackup还需要一个过程，称为prepare,这个过程所做的事情和mysql实例崩溃后所做的操作基本一致。利用坏的数据文件和事务日志进行rollback和forward操作。
4、xtrabckup本身链接了innodb相关的库,所在我们在prepare阶段看到innodb的启动和关闭信息，很类似于标准的mysql实例启动和关闭过程，实质是我们在prepare的时候，xtrabackup在调用innodb相关的代码进行实例恢复。prepare过后，xtrabackup备份文件就是一个一致性的数据拷贝，可以直接用来启动mysql。可以看到xtrabackup通过innodb的事务日志来和数据page，,进行实例恢复，然后得到一致性的备份。而对于那些非innodb的表则无能为力了，因为没有事务日志.所以我们可以看到在xtrackup备份Myisam的表，还是需要只读表锁来进行锁定，然后再备份数据文件，和普通的拷贝工具无异。
##三、xtrabackup工具使用
xtrabackup作为innodb的hotbackup工具，因开源，热备份和物理备份而在mysql中部署广泛。
####1、xtrabackup的安装部署
（1）先安装依赖包：
yum install perl-DBI
yum install perl-DBD-MySQL
yum install perl-Time-HiRes
yum install perl-IO-Socket-SSL
（2）下载并解压xtrabackup安装包：
cd /usr/local/
tar zxvf percona-xtrabackup-2.1.9-744-Linux-i686.tar.gz
（3）解压缩后的包内有两个子目录，bin目录下的命令可以直接使用，也可以复制到/usr/bin目录下再使用：
（4）试运行其中一个命令，如下：
说明命令使用没问题，为了方便直接使用，可以将bin下所有命令复制到/usr/bin目录下：
####2、innobakupex的完全备份
（1）创建一个最小权限的用户专门用于innobakupex备份：
mysql> create user ‘bkpuser‘@‘localhost‘ identified by ‘bkpuser‘;
Query OK, 0 rows affected (0.00 sec)
mysql> grant reload,lock tables,replication client on *.* to ‘bkpuser‘@‘localhost‘;
或者
mysql> grant reload,lock tables,replication client on *.* to ‘bkpuser‘@‘localhost‘ identified by ‘bkpuser‘;
（2）innobackupex的备份详解
[[email protected] bin]# innobackupex --socket=/httx/run/mysql/data/mysql.sock --defaults-file=/etc/my.cnf --user=bkpuser --password=bkpuser /opt/bkpdata/
XtraBackup对Innodb的备份之所以是热备，无需锁表，是基于Innodb自身的崩溃恢复机制，它首先复制所有的Innodb数据文件，这样复制出来的文件肯定是不一致的，然后对每个文件进行崩溃恢复处理，最终达到一致。就和MySQL在启动Innodb的时候一样，会通过比较数据文件头和redo log文件头信息来检查数据是否是一致的，如果不一致就尝试通过前滚(把redo log中所有提交的事务写入数据文件)和回滚(从数据文件中撤销所有redo log中未提交的事务引起的修改)来使数据达到最终一致。
XtraBackup在启动的时候会记录一个LSN(log sequence number)，然后就把所有的Innodb数据文件复制出来，这样复制出来的数据文件是不一致的， 但是XtraBackup会在后台运行一个进程把所有对redo log file的修改记录下来，只要有了这个数据，就能进行崩溃恢复。只所以要额外记录下来，是因为MySQL自身的redo log file是可重用的。
以上的操作是由xtrabackup二进制程序(比如xtrabackup_55)完成的，如果使用innobackupex 脚本，刚才的步骤完成以后，innobackupex就会去备份MyISAM表和.frm文件，这时要保证数据的一致性就会先锁表了，通过FLUSH TABLES WITH READ LOCK命令锁表然后把文件复制出来，再释放掉这个锁。
在恢复数据的时候，要经过prepare(recovery)和restore两个步骤。在prepare结束以后，Innodb的表恢复到了复制Innodb文件结束的时间点，这个时间 点也就是锁表复制MyISAM表的起点，所以最终数据是一致的。一般我们在恢复的时候执行两次prepare，是因为第二次prepare会帮助我们生成redo log文件，从而加快MySQL数据库启动的速度。
（3）innobackupex备份生成的文件详解：
[[email protected] 2016-08-30_08-33-02]# ll
total 12308
-rw-r--r-- 1 root root 238 Aug 30 08:33 backup-my.cnf
-rw-r----- 1 root root 12582912 Aug 30 08:33 ibdata1
drwx------ 2 root root 151 Aug 30 08:33 mysql
drwx------ 2 root root 90 Aug 30 08:33 test
-rw-r--r-- 1 root root 13 Aug 30 08:33 xtrabackup_binary
-rw-r--r-- 1 root root 24 Aug 30 08:33 xtrabackup_binlog_info
-rw-r----- 1 root root 77 Aug 30 08:33 xtrabackup_checkpoints
-rw-r----- 1 root root 2560 Aug 30 08:33 xtrabackup_logfile
默认情况下，不加--no-timestamp参数，备份数据会放在在指定的备份根目录下一个以时间戳命名的子目录下。备份目录下除了数据目录和文件以外，还有如下文件：
backup-my.cnf文件记录了源数据库的innodb表空间信息，便于恢复；
[[email protected] 2016-08-30_08-33-02]# cat backup-my.cnf
# This MySQL options file was generated by innobackupex.
# The MySQL server
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=50331648
innodb_page_size=16384
innodb_undo_tablespaces=0
xtrabackup_binary文件是记录了调用的xtrabackup的二进制版本，可以通过--ibbackup=IBBACKUP-BINARY参数来重新指定，一般和mysql版本对应：
[[email protected] 2016-08-30_08-33-02]# cat xtrabackup_binary
xtrabackup_56
xtrabackup_binlog_info文件：记录了备份时的binlog位点，也就是show master status可以查看到的；
[[email protected] 2016-08-30_08-33-02]# cat xtrabackup_binlog_info
mysql-bin.000001 2671
xtrabackup_checkpoints文件：记录了备份的类型（全量还是增量等），以及lsn的信息。
[[email protected] 2016-08-30_08-33-02]# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1744979
last_lsn = 1744979
xtrabackup_logfile文件：是个日志文件，XtraBackup会在后台运行一个进程把所有对redo log file的修改记录下来
[[email protected] 2016-08-30_08-33-02]# mysqlbinlog xtrabackup_logfile
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
ERROR: File is not a binary log file.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
####3、innobakupex的prepare
（1）执行prepare操作，回滚未提交事务，以及同步已提交事务至数据文件，使数据文件处于一致性状态：
innobackupex --apply-log /opt/bkpdata/2016-08-30_08-33-02/
其中，--apply-log参数是同xtrabackup的--prepare参数，一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据 文件仍处理不一致状态。--apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。
子目录/opt/bkpdata/2016-08-30_08-33-02/是备份时没有带--no-timestamp参数，因此备份数据放入指定备份根目录的以时间戳命名的子目录里。
####4、innobakupex的数据恢复
innobackupex --copy-back /path/to/BACKUP-DIR
从my.cnf读取datadir/innodb_data_home_dir/innodb_data_file_path等变量；
先复制MyISAM表，然后是innodb表，最后为logfile；--data-dir目录必须为空