背景介绍：
主库本来是没有从库的，已经跑了一段时间，已经有很多数据了，这时候需要建从库的话，需要先在主库做备份，然后再在从库进行恢复，恢复以后再开始同步，本篇是使用 xtrabackup工具进行备份恢复。
主库：192.168.247.130
从库：192.168.247.129
开始~
percona-xtrabackup安装
下载 xtrabackup ：
https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.7/binary/tarball/percona-xtrabackup-2.4.7-Linux-x86_64.tar.gz
解压
# tar zxvf percona-xtrabackup-2.4.7-Linux-x86_64.tar.gz
移动
# mv percona-xtrabackup-2.4.7-Linux-x86_64 usr/local/xtrabackup
添加到基本命令：
cp usr/local/xtrabackup/bin/xtrabackup usr/bin
查看版本
xtrabackup --versionxtrabackup version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 05f1fcf)
创建一个备份的用户给他最小的权限
create user 'bkpuser'@localhost identified by 'bkpuser';grant reload,lock tables,process,replication client on *.* to 'bkpuser'@'localhost';flush privileges;
创建备份目录
cd /home/mysqlmkdir xtrabackupchown -R mysql:mysql xtrabackup/
普通全量备份
innobackupex --no-timestamp --user=bkpuser --password='bkpuser' --parallel=4 home/mysql/xtrabackup/all_back_20200108
把文件从一台服务器复制到另一台服务器（注意打包以后再传输，不能传输文件夹）
# scp home/mysql/xtrabackup/all_back_20200108.tar root@192.168.247.129:/home/mysql/xtrabackuproot@192.168.247.129's password: （输入129服务器的root密码）all_back_20200108.tar 100% 3741KB 3.7MB/s 00:00
遇到过的报错：
报错1：ssh: connect to host 192.168.247.129 port 22: No route to host
解决：ping 不通导致，重启后IP地址变了，修改为固定IP地址，重启网络service network restart 即可
报错2：
The authenticity of host '192.168.247.129 (192.168.247.129)' can't be established.
解决：
修改/etc/ssh/ssh_config文件的配置，以后则不会再出现此问题
最后面添加：
StrictHostKeyChecking noUserKnownHostsFile dev/null
报错3：
/home/mysql/xtrabackup/all_back_20200108: not a regular file
解决：不能直接传输文件夹，先压缩再传输
tar czvf all_back_20200108.tar all_back_20200108/ all_back_20200108/
以下操作在从库进行：
备份完成后，还不能用于恢复，一些未提交的事物需要恢复，需要恢复redo logo的数据，确保数据一致
创建备份后并不能直接用于恢复.需要先prepare。prepare的目的是跑一下redo,将未提交的rollback,回滚的回滚,跑出一个一致性的备份。
innobackupex --apply-log home/mysql/xtrabackup/all_back_20200108
在129上关闭同步：stop slave
将129服务器的/home/mysql/data目录清空，注意如果你的binlog在此目录下，不要删除binlog
关闭服务：
service mysqld stop
查看MySQL进程并杀死（可忽略）
ps -e|grep mysqlkill -9 2891
解压备份文件
cd /home/mysql/xtrabackuptar -zxvf all_back_20200108.tar
清空/home/mysql/data文件里面的内容
cd /home/mysql/datarm -rf *
注意还要清空/home/mysql/binlog 和 home/mysql/tmp 文件夹下面的内容
开始恢复
innobackupex --defaults-file=/etc/my.cnf --copy-back home/mysql/xtrabackup/all_back_20200108
成功以后打开服务
service mysqld start
遇到的报错处理：
Starting MySQL.Logging to '/home/mysql/data/mysql-error.log'. . ERROR! The server quit without updating PID file (/home/mysql/data/mysqld.pid).
没有写mysql.pid的权限，授权
cd /home/mysql/datachown -R mysql:mysql *
这里的建议是在129上做恢复的时候用mysql用户进行就不会出现该报错
需要重新打开主从复制
show master status\G*************************** 1. row ***************************File: mysql-bin.000009Position: 274Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 3eb70318-2e0a-11ea-a5e4-000c29050520:1, 44d27feb-3139-11ea-9e1e-000c29e38e77:1-2:8-19, deb7835b-31df-11ea-af79-000c29050520:11 row in set (0.00 sec)
首先在从库做一下：
reset master
这个动作会删除所有binlog文件mysql-bin.00001.....，千万不要在生产上做。。
去主库查看：
show master status\G *************************** 1. row ***************************File: master-bin.000001Position: 4445Binlog_Do_DB:Binlog_Ignore_DB: mysql,information_schema,performance_schema,performance_schema,sysExecuted_Gtid_Set: 44d27feb-3139-11ea-9e1e-000c29e38e77:1-21
可见：主库是1-21节点要同步给从库
去查看下当前从库通过备份已经恢复到主库的哪个节点
cat home/mysql/data/xtrabackup_info......binlog_pos = filename 'master-bin.000001', position '3448', GTID of the last change '44d27feb-3139-11ea-9e1e-000c29e38e77:1-17'......
可以看到从库已经有1-17节点，也就是说1-17是不用再进行同步的
(root@localhost) [(none)]> show variables like '%purge%';+--------------------------------------+-------+| Variable_name | Value |+--------------------------------------+-------+| gtid_purged | || innodb_max_purge_lag | 0 || innodb_max_purge_lag_delay | 0 || innodb_purge_batch_size | 300 || innodb_purge_rseg_truncate_frequency | 128 || innodb_purge_threads | 2 || relay_log_purge | ON |+--------------------------------------+-------+7 rows in set (0.04 sec)
从库再查看下：
show master status\G*************************** 1. row ***************************File: mysql-bin.000001Position: 154Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: （注意这里是空的了）
确保Executed_Gtid_Set: 是空的，再执行set global gtid_purged 操作
set global gtid_purged='44d27feb-3139-11ea-9e1e-000c29e38e77:1-17';
从库再查看下：
show master status\G*************************** 1. row ***************************File: mysql-bin.000001Position: 154Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set:44d27feb-3139-11ea-9e1e-000c29e38e77:1-17
因为此时Gtid是打开的，只能用Gtid来进行change master
change master to master_host='192.168.247.130', master_port=3306, master_user='repl',master_password='repl',master_auto_position=1;
然后开始同步
start slave;
完成
又练习了另一种情况，目前只有几天之前的全备，再做一个增量备份，然后在从库进行恢复，打开slave
增量备份
基于 all_back_20200108 节点进行增量备份：
innobackupex --user=bkpuser --password='bkpuser' --incremental-basedir=/home/mysql/xtrabackup/all_back_20200108 --incremental home/mysql/xtrabackup
比较之前的全量备份语句：
innobackupex --no-timestamp --user=bkpuser --password='bkpuser' --parallel=4 home/mysql/xtrabackup/all_back_20200108
传输（使用root用户进行）
scp 2020-01-10_09-46-32.tar root@192.168.247.129:/home/mysql/xtrabackup
在从库进行恢复：
首先apply-log
先进行全备份的日志应用：
innobackupex --apply-log --redo-only /home/mysql/xtrabackup/all_back_20200108
因为后面还有增量备份，需要加--redo-only，如果是最后一个备份就不用加了。
进行增量备份的apply-log，注意路径是全路径
innobackupex --apply-log --incremental /home/mysql/xtrabackup/all_back_20200108 --incremental-dir=/home/mysql/xtrabackup/2020-01-10_09-46-32
删除/data 和 /binlog 下数据，确保当前MySQL没有在运行，开始恢复
innobackupex --defaults-file=/etc/my.cnf --copy-back /home/mysql/xtrabackup/all_back_20200108
启动MySQL
service mysqld start
然后开启slave
开启方式同上
一路踩坑，记录下来希望之后不会再犯~~
推荐书籍：《MySQL管理之道 性能调优、高可用与监控》 贺春旸著
适合新人，包含实操的语句，简单易懂
缺点：出版时间较久了，使用的MySQL版本是5.5，不过影响不大~
