运维笔记：利用 xtrabackup 进行线上 MySQL 数据库主从恢复

xtrabackup介绍

Percona XtraBackup（简称PXB）是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB，并且全部开源，真可谓是业界良心。

xtrabackup命令参数解释

--defaults-file
同 xtrabackup 的 --defaults-file 参数
--apply-log
对xtrabackup的–prepare参数的封装
--copy-back
做数据恢复时将备份数据文件拷贝到MySQL服务器的datadir ；
--remote-host=HOSTNAME
通过ssh将备份数据存储到进程服务器上；
--stream=[tar]
备 份文件输出格式, tar时使用tar4ibd , 该文件可在XtarBackup binary文件中获得.如果备份时有指定–stream=tar, 则tar4ibd文件所处目录一定要在$PATH中(因为使用的是tar4ibd去压缩, 在XtraBackup的binary包中可获得该文件)。
在 使用参数stream=tar备份的时候，你的xtrabackup_logfile可能会临时放在/tmp目录下，如果你备份的时候并发写入较大的话 xtrabackup_logfile可能会很大(5G+)，很可能会撑满你的/tmp目录，可以通过参数–tmpdir指定目录来解决这个问题。
--tmpdir=DIRECTORY
当有指定–remote-host or --stream时, 事务日志临时存储的目录, 默认采用MySQL配置文件中所指定的临时目录tmpdir
--redo-only
强制备份日志时只redo ,跳过rollback。这在做增量备份时非常必要。
--use-memory=#
该参数在prepare的时候使用，控制prepare时innodb实例使用的内存量
--throttle=IOS
同xtrabackup的–throttle参数
--sleep=是给ibbackup使用的，指定每备份1M数据，过程停止拷贝多少毫秒，也是为了在备份时尽量减小对正常业务的影响，具体可以查看ibbackup的手册 ；
--compress[=LEVEL]
对备份数据迚行压缩，仅支持ibbackup，xtrabackup还没有实现；
--include=REGEXP
对 xtrabackup参数–tables的封装，也支持ibbackup。备份包含的库表，例如：–include=“test."，意思是要备份 test库中所有的表。如果需要全备份，则省略这个参数；如果需要备份test库下的2个表：test1和test2,则写 成：–include=“test.test1|test.test2”。也可以使用通配符，如：–include="test.test”。
--databases=LIST
列出需要备份的databases，如果没有指定该参数，所有包含MyISAM和InnoDB表的database都会被备份；
--uncompress
解压备份的数据文件，支持ibbackup，xtrabackup还没有实现该功能；
--slave-info
备 份从库, 加上–slave-info备份目录下会多生成一个xtrabackup_slave_info 文件, 这里会保存主日志文件以及偏移, 文件内容类似于:CHANGE MASTER TO MASTER_LOG_FILE=’’, MASTER_LOG_POS=0
--socket=SOCKET
指定mysql.sock所在位置，以便备份进程登录mysql.

恢复MySQL主从

数据库主从因为各种原因断了，而且没办法恢复。线上数据库也不能停止。这时候想恢复主从关系就可以借助热备份工具xtrabackup。

第一步：备份线上数据库

[root@ddz_db5 data]# innobackupex --slave-info /data/

如果没有指定备份目录，xtrabackup会在当前目录自动生成以当前时间命名的备份文件夹。100G数据用时在半小时左右。

[root@ddz_db5 data]# ll
drwxr-x--- 5 root  root     4096 May 27 10:16 2017-05-27_09-57-24
drwxr-xr-x 5 mysql mysql    4096 May 27 16:40 mysql

第二步：xtrabackup --apply-log把已提交的事务合并到ibdata文件
这一步持续时间会很长，1小时左右。

[root@ddz_db5 data] xtrabackup --apply-log 2017-05-27_09-57-24
170527 11:10:23 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".

innobackupex version 2.4.7 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 6f7a799)
xtrabackup: cd to /data/2017-05-27_10-36-22/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=822542336, start_lsn=(16153415803165)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
...

InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 16153415803165
InnoDB: Doing recovery: scanned up to log sequence number 16153421045760 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 16153426288640 (1%)
InnoDB: Doing recovery: scanned up to log sequence number 16153431531520 (2%)
InnoDB: Doing recovery: scanned up to log sequence number 16153436774400 (2%)
InnoDB: Doing recovery: scanned up to log sequence number 16153442017280 (3%)
InnoDB: Doing recovery: scanned up to log sequence number 16153447260160 (4%)
InnoDB: Doing recovery: scanned up to log sequence number 16153452503040 (5%)
InnoDB: Doing recovery: scanned up to log sequence number 16153457745920 (5%)
InnoDB: Doing recovery: scanned up to log sequence number 16153462988800 (6%)
...
InnoDB: Doing recovery: scanned up to log sequence number 16153788440576 (50%)
InnoDB: Doing recovery: scanned up to log sequence number 16153793683456 (51%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 16153798926336 (52%)
InnoDB: Doing recovery: scanned up to log sequence number 16153804169216 (53%)

第三步：scp备份目录到从机

[root@ddz_db5 data] scp -r 2017-05-27_09-57-24 slave:/data/

第四步：启动从机的数据库

[root@slave data] mv 2017-05-27_09-57-24 mysql
[root@slave data] service mysqld start

第五步：建立主从关系

[root@slave data] cat mysql/xtrabackup_binlog_info
mysqlbin-log.011197     1057212057
[root@slave data] mysql
...
mysql> change master to master_host='master',master_user='slave',master_password='slave',master_log_file='mysqlbin-log.011197',master_log_pos=1057212057;
mysql> start slave;

以上，不需要停止线上业务，成功恢复了主从关系。

热备份数据库

TODO

从热备恢复数据

TODO

参考

https://www.percona.com
MySQL · 物理备份 · Percona XtraBackup 备份原理
mysql之使用xtrabackup进行物理备份、恢复、在线克隆从库、在线重做主从
mysql innobackupex xtrabackup 大数据量 备份 还原