共计 4181 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章将为大家详细讲解有关如何用 Percona Xtrabackup 恢复 MySQL 从库，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
同样的，还是一台服务器上两个实例。3306 端口的实例为主库，3307 端口的实例为从库。
现在，手动将备库里的数据清空掉，模拟备库被破坏。
drop database test2；
采用 Percona Xtrabackup 来恢复从库。
Percona Xtrabackup 是一款开源的备份工具，这个工具可以在 Percona 的官方网站上下载来进行安装。
恢复步骤如下：
1、对主库的数据进行完全备份，注意，这个是热备，不需要停库的
innobackupex –default-file=/usr/local/mysql/my.cnf –user=root –password=root –socket=/usr/local/mysql/mysql.sock /tmp/backup
如果屏幕输出的结尾有打印“completed Ok!”，则表示命令执行成功。
2、将主库生成的日志附加到备份中
innobackupex –apply-log /tmp/backup/2016-08-30_09-56-23
同步骤 1 一样，如果屏幕输出的结尾有 completed OK 的字输出，表示命令执行成功。
3、查看主库生成的备份信息
[root@single1 2016-08-30_09-56-23]# ls -l
total 131108
-rw-r—–. 1 root root 418 Aug 30 09:56 backup-my.cnf
-rw-r—–. 1 root root 12582912 Aug 30 09:56 ibdata1
-rw-r—–. 1 root root 50331648 Aug 30 09:56 ib_logfile0
-rw-r—–. 1 root root 50331648 Aug 30 09:56 ib_logfile1
-rw-r—–. 1 root root 12582912 Aug 30 09:56 ibtmp1
drwxr-x—. 2 root root 4096 Aug 30 09:56 lxm
drwxr-x—. 2 root root 4096 Aug 30 09:56 mysql
drwxr-x—. 2 root root 4096 Aug 30 09:56 performance_schema
drwxr-x—. 2 root root 4096 Aug 30 09:56 test
-rw-r—–. 1 root root 21 Aug 30 09:56 xtrabackup_binlog_info
-rw-r–r–. 1 root root 21 Aug 30 09:56 xtrabackup_binlog_pos_innodb
-rw-r—–. 1 root root 113 Aug 30 09:56 xtrabackup_checkpoints
-rw-r—–. 1 root root 504 Aug 30 09:56 xtrabackup_info
-rw-r—–. 1 root root 8388608 Aug 30 09:56 xtrabackup_logfile
注：
a) xtrabackup_binlog_info 文件记录 mysql 服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
b) xtrabackup_binlog_pos_innodb 文件记录二进制日志文件及用于 InnoDB 或 XtraDB 表的二进制日志文件的当前 position。
（xtrabackup_binlog_info 文件和 xtrabackup_binlog_pos_innodb 文件的区别：对于纯 InnoDB 操作，备份出来的数据中上述两个文件的内容是一致的。对于 InnoDB 和非事务存储引擎混合操作，xtrabackup_binlog_info 中所示的 position 应该会比 xtrabackup_pos_innodb 所示的数值大。此时应以 xtrabackup_binlog_info 为准；而后者和 apply-log 时 InnoDB recovery log 中显示的内容是一致的，只针对 InnoDB 这部分数据。）
c) xtrabackup_checkpoints 文件用来描述备份类型，备份状态，LSN 范围信息。
d) xtrabackup_info 文件记录备份时所用 xtrabackup 命令的一些信息
e) backup-my.cnf 文件为备份命令用到的配置选项信息；
4、恢复从库
停止从库服务，将从库中原有的数据清空。
service mysql3307 stop;
cd /usr/local/mysql3307
mv data data.bak
然后开始恢复：
innobackupex –defaults-file=/usr/local/mysql3307/my.cnf –copy-back –rsync /tmp/backup/2016-08-30_09-56-23
如果屏幕输出的结尾有打印“completed Ok!”，则表示命令执行成功。
5、修改从库数据文件的属性
从库恢复成功后，可以在 /usr/local/mysql3307 目录下，看到一个 data：
记得将这个恢复过来的 data 目录属组全部改回 mysql，否则启动从库时会如下错误：
chown -R mysql:mysql data
6、查看备份中 binary log 的信息
[root@single1 2016-08-30_09-56-23]# cat xtrabackup_binlog_info
mysql-bin.000003 329
7、起从库，重新同步：
service mysql3307 start
mysql -S /usr/local/mysql3307/mysql.sock -P 3307 -uroot -p
mysql change master to master_host= localhost , master_user= root , master_password= root , master_log_file= mysql-bin.000003 , master_log_pos=329, master_port=3306;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
#master_log_file 参数和 master_log_pos 参数的设置就是根据第 6 步得来的
mysql start slave;
Query OK, 0 rows affected (0.01 sec)
mysql show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: localhost
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 329
Relay_Log_File: single1-relay-bin.000002
Relay_Log_Pos: 283
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 329
Relay_Log_Space: 458
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 9c534d95-6849-11e6-bae6-000c295ae8a5
Master_Info_File: /usr/local/mysql3307/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
ERROR:
No query specified
8、检验主库和从库是否一致。
关于如何用 Percona Xtrabackup 恢复 MySQL 从库就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
