前期写的mysql热备份脚本恢复，还没有正式用到过，但是今天演练灾备恢复，但是遇到几个问题。
测试环境：
搭建mysql，安装xtrabackup
vim /etc/yum.repos.d/Percona.repo
[percona] name = CentOS $releasever - Percona baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/ enabled = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona gpgcheck = 0
yum install percona-xtrabackup.x86_64 -y
1、演练恢复数据：
拿到生产环境备份数据，运行恢复数据脚本。http://www.cnblogs.com/jjzd/p/6659607.html
结果运行失败，原因是全量备份日期计算错误，原脚本已修改。
2、停掉mysql，删除mysql数据（移动/var/lib/mysql到/var/lib/mysql_bak）
3、运行修改备份恢复脚本。
4、修改权限，chown -R mysql.mysql /var/lib/mysql
5、启动mysql，service mysql restart，报错：
Starting MySQL...The server quit without updating PID file (/var/lib/mysql/mysql.pid).[失败]
原因最好的办法是先查看下错误日志：
（1）、可能是/var/lib/mysql/mysql.pid文件没有写的权限
解决方法 ：给予权限，然后重新启动mysqld！
（2）、可能进程里已经存在mysql进程
解决方法：用命令“ps -ef|grep mysqld”查看是否有mysqld进程，如果有使用“kill -9 进程号”杀死，然后重新启动mysqld！
（3）、可能是第二次在机器上安装mysql，有残余数据影响了服务的启动。
解决方法：去mysql的数据目录/data看看，如果存在mysql-bin.index，就赶快把它删除掉吧，它就是罪魁祸首了。
（4）、mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。
解决方法：请在[mysqld]下设置这一行：datadir = /usr/local/mysql/data
（5）、skip-federated字段问题
解决方法：检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。
（6）、错误日志目录不存在
解决方法：使用“chown” “chmod”命令赋予mysql所有者及权限
（7）、selinux惹的祸，如果是centos系统，默认会开启selinux
解决方法：关闭它，打开/etc/selinux/config，把SELINUX=enforcing改为SELINUX=disabled后存盘退出重启机器试试。本人就是使用第三条方法解决的 ！
故障排除完后，启动数据库，恢复上一次备份后产生的数据变化：
6、恢复二进制文件：
去完全备份的目录下查看一下当时备份时候binlog的日志信息（因为增量备份是被应用到完全备份里的，当然，查看最后一次增量备份目录中的这个文件信息也可以，其实两个内容是一样的）
[root@manager1 mysql]# cat xtrabackup_binlog_pos_innodb mysql-bin.000001 3710 #读取该二进制日志的位置并保存至.sql文件 [root@manager1 ~]# mysqlbinlog --start-position=3710 /var/lib/mysql_bak/mysql-bin.000001 > /tmp/1.sql [root@manager1 mysql]# mysql -h127.0.0.1 -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 5 Server version: 5.6.37-log MySQL Community Server (GPL) Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or 'h' for help. Type 'c' to clear the current input statement. #进入mysql且先关闭二进制功能，进行恢复，再开启二进制功能： mysql> set sql_log_bin = 0; Query OK, 0 rows affected (0.55 sec) mysql> source /tmp/1.sql; Query OK, 0 rows affected (0.01 sec) Query OK, 0 rows affected, 1 warning (0.00 sec) Query OK, 0 rows affected (0.00 sec)
自此，恢复OK，进入数据库可以检查数据。
注意，当脚本不能自动恢复时，紧急情况下，请手动恢复，步骤无非就是在全量的基础上增量恢复：
先进行完全备份的准备： innobackupex --apply-log --redo-only /backup/2017-10-17_01-09-48/ 再进行增量备份的准备： innobackupex --apply-log --redo-only /backup/2017-10-17_01-09-48/ --incremental-dir=/backup/2017-10-17_13-26-38/ 确保2次操作都出现成功的提示： completed OK! 因为增量备份的数据都已合并到完全备份中去了，所以此时只恢复完全备份即可 innobackupex --copy-back /backup/2017-10-17_01-09-48/
手动备份：
全量：innobackupex --user=backup -password=123456 /backup/增量备份：innobackupex -user=backup -password=123456 --incremental /backup --incremental-basedir=BASEDIR
xtrabackup_checkpoints ： 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态，这个为准备工作，包括事务日志和数据文件，把事务日志中已提交的事务同步至数据文件，未提交的进行回滚）和LSN(日志序列号)范围信息；每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。查看一下其内容：
cat xtrabackup_checkpoints backup_type = full-backuped # 表示备份类型为完全备份 from_lsn = 0 # LSN号从0开始 to_lsn = 5618613 # LSN号到0结束 last_lsn = 5618613 # 最后的lsn号，换句话说，一会进行增量备份时会以这个数字开始，可以理解为 xtrabackup为每次备份打的开始和结束的标记 compact = 0 # 0表示未启用压缩
xtrabackup_binlog_info： mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置；
xtrabackup_binary：备份中用到的xtrabackup的可执行文件；
backup-my.cnf：备份命令用到的配置选项信息，也就是my.cnf配置文件中定义的相关参数