Xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份（备份时不影响数据读写），是商业备份工具InnoDB Hotbackup的一个很好的替代品。
一、 Xtrabackup概述
它能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份（对于MyISAM的备份同样需要加表锁）。XtraBackup支持所有的Percona Server、MySQL、MariaDB和Drizzle。
xtrabackup有两个主要的工具：xtrabackup、innobackupex
（1） xtrabackup只能备份InnoDB和XtraDB 两种数据表
（2） innobackupex则封装了xtrabackup,同时可以备份MyISAM数据表
Innobackupex完整备份后生成了几个重要的文件：
（1） xtrabackup_binlog_info：记录当前最新的LOG Position
（2） xtrabackup_binlog_pos_innodb: innodb log postion
（3） xtrabackup_checkpoints: 存放备份的起始位置beginlsn和结束位置endlsn,增量备份需要这个lsn[增量备份可以在这里面看from和to两个值的变化]
Xtrabackup特点：
（1） 备份过程快速、可靠
（2） 备份过程不会打断正在执行的事务
（3） 能够基于压缩等功能节约磁盘空间和流量
（4） 自动实现备份检验
（5） 还原速度快
二、Xtrabackup原理
不管是使用innobackupex还是xtrabackup工具进行备份和恢复，都有3个步骤：备份(backup)、准备(prepare)、恢复(copy back)。
2.1备份阶段（backup）
（1） 在启动xtrabackup时记下LSN并将redo log拷贝到备份目标目录下的xtrabackup_logfile文件中。由于拷贝需要一定时间，如果在拷贝时间段内有日志写入，将导致拷贝的日志和MySQL的redo log不一致，所以xtrabackup还有一个后台进程监控着mysql的redo log，每秒监控一次，当MySQL的redo log有变化，该监控进程会立即将变化的内容写入到xtrabackup_logfile文件，这样就能保证拷贝走的redo log中记录了一切变化。但是这也是有风险的，因为redo是轮训式循环写入的，如果某一时刻有非常大量的日志写到redo log中，使得还没开始复制的日志就被新日志覆盖了，这样会日志丢失，并报错。
（2） 拷贝完初始版的redo log后，xtrabackup开始拷贝innodb表的数据文件(即表空间文件.ibd文件和ibdata1)。注意，此时不拷贝innodb的frm文件。
（3） 当innodb相关表的数据文件拷贝完成后，xtrabackup开始准备拷贝非innodb的文件。但在拷贝它们之前，要先对非innodb表进行加锁防止拷贝时有语句修改这些类型的表数据。
对于不支持backup lock的版本，只能通过flush tables with read lock来获取全局读锁，但这样也同样会锁住innodb表，杀伤力太大。所以使用xtrabackup备份Oracle的MySQL，实质上只能实现innodb表的部分时间热备、部分时间温备。对于支持backup lock的版本，xtrabackup通过lock tables for backup获取轻量级的backup locks来替代flush tables with read lock，因为它只锁定非innodb表，所以由此实现了innodb表的真正热备。
（4） 当获取到非innodb表的锁以后，开始拷贝非innodb表的数据和.frm文件。当这些拷贝完成之后，继续拷贝其他存储引擎类型的文件。(实际上，拷贝非innodb表的数据是在获取backup locks(如果支持)后自动进行的，它们属于同一个过程)
（5） 当拷贝阶段完成后，就到了备份的收尾阶段。包括获取二进制日志中一致性位置的坐标点、结束redo log的监控和拷贝、释放锁等。
对于不支持backup lock的版本，收尾阶段的过程是这样的：获取二进制日志的一致性坐标点、结束redo log的监控和拷贝、释放锁。
对于支持backup lock的版本，收尾阶段的过程是这样的：先通过lock binlog for bakcup来获取二进制日志锁，然后结束redo log的监控和拷贝，再unlock tables释放表锁，随后获取二进制日志的一致性位置坐标点，最后unlock binlog释放二进制日志锁。
（6） 如果一切都OK，xtrabackup将以状态码0退出。所以，对是否支持backup lock的版本，xtrabackup备份的时的行为是不一样的。
2.2准备阶段（prepare）
由于备份的时候拷贝走的数据文件可能是不一致的，比如监控着MySQL的redo log中在拷贝过程完成后又新的事务提交了，而拷贝走的数据是未提交状态的，那么就需要对该事务前滚；如果监控到的日志中有事务未提交，那么该事务就需要回滚。
但是如果只备份了myisam表或其他非事务表数据，因为备份阶段直接锁定了这些表，所以不会有不一致的状态。
xtrabackup有一个"准备"的阶段。这个阶段的实质就是对备份的innodb数据应用redo log，该回滚的回滚，该前滚的前滚，最终保证xtrabackup_logfile中记录的redo log已经全部应用到备份数据页上，并且实现了一致性。当应用结束后，会重写"xtrabackup_logfile"再次保证该redo log和备份的数据是对应的。
准备过程不需要连接数据库，该过程可以在任意装了xtrabackup软件的机器上进行，之所能实现是因为xtrabackup软件的内部嵌入了一个简化的innodb存储引擎，可以通过它完成日志的应用。
2.3恢复阶段（copy back）
xtrabackup的恢复过程实质是将备份的数据文件和结构定义等文件拷贝回MySQL的datadir。同样可以拷贝到任意机器上。
要求恢复之前MySQL必须是停止运行状态，且datadir是空目录，除非恢复的操作是导入表的操作。具体见后文对应的内容。
三、 Percona XtraBackup 8.0概述
目前只发布了Percona XtraBackup 8.0.1 alpha版本，是一个 XtraBackup for MySQL 8.0 版本，兼容于 MySQL 8.0 备份。
值得注意的事项：
（1） 删除了已弃用的 innobackupex 命令 。
（2） 由于 MySQL 8.0 数据目录以及 redo 格式的变化，新的 Xtrabackup for MySQL 8.0 仅兼容 MySQL 8.0 ，以及即将推出的 Percona Server for MySQL 8.0.x 。
（3） 对于更早的版本的迁移，需要使用 XtraBackup 2.4 来备份和恢复，然后使用 MySQL 8.0.x 中的 mysql_upgrade 。
目前 percona xtrabackup 8.0 可用于以下平台：
（1） RHEL Centos 6.x
（2） RHEL Centos 7.x
（3） Ubuntu 14.04 Trusty *
（4） Ubuntu 16.04 Xenial
（5） Ubuntu 18.04 Bionic
（6） Debian 8 Jessie *
（7） Debian 9 Stretch
xtrabackup工具有两种常用运行模式："--backup"和"--prepare"。还有两个比较少用的模式："--stats"和"--print-param"。
四、 XtraBackup for MySQL 8.0安装
依赖系统包：libev.so.4()(64bit) perl(DBD::mysql)
[root@sjs_21_219 ~]# yum install libev.so*
[root@sjs_21_219 opt]# yum install perl-DBD-MySQL
[root@sjs_21_219 opt]# rpm -ivh percona-xtrabackup-80-8.0.1-1.alpha.el7.x86_64.rpm
warning: percona-xtrabackup-80-8.0.1-1.alpha.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
Preparing... ################################# [100%]
Updating installing...
1:percona-xtrabackup-80-8.0.1-1.alp################################# [100%]
[root@sjs_21_219 ~]# xtrabackup -v
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql
xtrabackup version 8.0.1 based on MySQL server 8.0.11 Linux (x86_64) (revision id: )
[root@sjs_21_219 ~]#
[root@sjs_21_219 ~]# xtrabackup --help
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql
xtrabackup: recognized client arguments: --datadir=/var/lib/mysql
xtrabackup version 8.0.1 based on MySQL server 8.0.11 Linux (x86_64) (revision id: )
Open source backup tool for InnoDB and XtraDB
You can download full text of the license on http://www.gnu.org/licenses/gpl-2.0.txt
Usage: [xtrabackup [--defaults-file=#] --backup | xtrabackup [--defaults-file=#] --prepare] [OPTIONS]
Default options are read from the following files in the given order:
/etc/my.cnf etc/mysql/my.cnf usr/etc/my.cnf ~/.my.cnf
The following groups are read: xtrabackup mysqld
The following options may be given as the first argument:
--print-defaults Print the program argument list and exit.
--no-defaults Don't read default options from any option file,
except for login file.
--defaults-file=# Only read default options from the given file #. 默认配置文件的路径
--defaults-extra-file=# Read this file after the global files are read.
--defaults-group-suffix=#
Also read groups with concat(group, suffix)
--login-path=# Read this path from the login file.
-v, --version print xtrabackup version information
--target-dir=name destination directory 备份文件的存放目录路径
--backup take backup to target-dir 实施备份到target-dir
五、 XtraBackup for MySQL 8.0参数
参数名 | 描述 | 备注 |
--apply-log-only | prepare备份的时候只执行redo阶段，用于增量备份。 | |
--backup | 创建备份并且放入--target-dir目录中 | |
--close-files | 不保持文件打开状态，xtrabackup打开表空间的时候通常不会关闭文件句柄，目的是为了正确处理DDL操作。如果表空间数量非常巨大并且不适合任何限制，一旦文件不在被访问的时候这个选项可以关闭文件句柄.打开这个选项会产生不一致的备份。 | |
--compact | 创建一份没有辅助索引的紧凑备份 | |
--compress | 压缩所有输出数据，包括事务日志文件和元数据文件，通过指定的压缩算法，目前唯一支持的算法是quicklz.结果文件是qpress归档格式，每个xtrabackup创建的*.qp文件都可以通过qpress程序提取或者解压缩 | |
--compress-chunk-size | 压缩线程工作buffer的字节大小，默认是64K | |
--compress-threads | xtrabackup进行并行数据压缩时的worker线程的数量，该选项默认值是1，并行压缩（'compress-threads'）可以和并行文件拷贝('parallel')一起使用。例如:'--parallel=4 --compress --compress-threads=2'会创建4个IO线程读取数据并通过管道传送给2个压缩线程。 | |
--create-ib-logfile | 这个选项目前还没有实现，目前创建Innodb事务日志，你还是需要prepare两次。 | |
--datadir=DIRECTORY | backup的源目录，mysql实例的数据目录。从my.cnf中读取，或者命令行指定。 | |
--defaults-extra-file=[MY.CNF] | 在global files文件之后读取，必须在命令行的第一选项位置指定。 | |
--defaults-file=[MY.CNF] | 唯一从给定文件读取默认选项，必须是个真实文件，必须在命令行第一个选项位置指定。 | |
--defaults-group=GROUP-NAME | 从配置文件读取的组，innobakcupex多个实例部署时使用。 | |
--export | 为导出的表创建必要的文件 | |
--extra-lsndir=DIRECTORY(for --bakcup) | 在指定目录创建一份xtrabakcup_checkpoints文件的额外的备份。 | |
--incremental-basedir=DIRECTORY | 创建一份增量备份时，这个目录是增量别分的一份包含了full bakcup的Base数据集。 | |
--incremental-dir=DIRECTORY | prepare增量备份的时候，增量备份在DIRECTORY结合full backup创建出一份新的full backup。 | |
--incremental-force-scan | 创建一份增量备份时，强制扫描所有增在备份中的数据页即使完全改变的page bitmap数据可用。 | |
--incremetal-lsn=LSN | 创建增量备份的时候指定lsn。 | |
--innodb-log-arch-dir | 指定包含归档日志的目录。只能和xtrabackup --prepare选项一起使用。 | |
--innodb-miscellaneous | 从My.cnf文件读取的一组Innodb选项。以便xtrabackup以同样的配置启动内置的Innodb。通常不需要显示指定。 | |
--log-copy-interval | 这个选项指定了log拷贝线程check的时间间隔（默认1秒）。 | |
--log-stream | xtrabakcup不拷贝数据文件，将事务日志内容重定向到标准输出直到--suspend-at-end文件被删除。这个选项自动开启--suspend-at-end。 | |
--no-defaults | 不从任何选项文件中读取任何默认选项,必须在命令行第一个选项。 | |
--databases | 指定了需要备份的数据库和表。 | |
--database-file | 指定包含数据库和表的文件格式为databasename1.tablename1为一个元素，一个元素一行。 | |
--parallel | 指定备份时拷贝多个数据文件并发的进程数，默认值为1。 | |
--prepare | xtrabackup 在一份通过--backup生成的备份执行还原操作，以便准备使用。 | |
--print-default | 打印程序参数列表并退出，必须放在命令行首位。 | |
--print-param | 使xtrabackup打印参数用来将数据文件拷贝到datadir并还原它们。 | |
--rebuild_indexes | 在apply事务日志之后重建innodb辅助索引，只有和--prepare一起才生效。 | |
--rebuild_threads | 在紧凑备份重建辅助索引的线程数，只有和--prepare和rebuild-index一起才生效。 | |
--stats | xtrabakcup扫描指定数据文件并打印出索引统计。 | |
--stream=name | 将所有备份文件以指定格式流向标准输出，目前支持的格式有xbstream和tar。 | |
--suspend-at-end | 使xtrabackup在--target-dir目录中生成xtrabakcup_suspended文件。在拷贝数据文件之后xtrabackup不是退出而是继续拷贝日志文件并且等待知道xtrabakcup_suspended文件被删除。这项可以使xtrabackup和其他程序协同工作。 | |
--tables=name | 正则表达式匹配database.tablename。备份匹配的表。 | |
--tables-file=name | 指定文件，一个表名一行。 | |
--target-dir=DIRECTORY | 指定backup的目的地，如果目录不存在，xtrabakcup会创建。如果目录存在且为空则成功。不会覆盖已存在的文件。 | |
--throttle | 指定每秒操作读写对的数量。 | |
--tmpdir=name | 当使用--print-param指定的时候打印出正确的tmpdir参数。 | |
--to-archived-lsn=LSN | 指定prepare备份时apply事务日志的LSN，只能和xtarbackup --prepare选项一起用。 | |
--user-memory | 通过--prepare prepare备份时候分配多大内存，目的像innodb_buffer_pool_size。默认值100M如果你有足够大的内存。1-2G是推荐值，支持各种单位(1MB,1M,1GB,1G)。 | |
--version | 打印xtrabackup版本并退出。 | |
--xbstream | 支持同时压缩和流式化。需要客服传统归档tar,cpio和其他不允许动态streaming生成的文件的限制，例如动态压缩文件，xbstream超越其他传统流式/归档格式的的优点是，并发stream多个文件并且更紧凑的数据存储（所以可以和--parallel选项选项一起使用xbstream格式进行streaming） |
六、 XtraBackup for MySQL 8.0备份和恢复测试
6.1 Xtrabackup实现全备及恢复
（1） 全量备份过程
和innobackupex备份过程不同的是，xtrabackup的备份路径是由"--target-dir"选项严格指定的，如果指定的目录不存在，它备份的时候不会在target-dir目录中再创建时间戳子目录。
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --backup --target-dir=/data/3399
或者用--datadir取代--defaults-file
xtrabackup --datadir=/data/mydata/my3399/ --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --backup --target-dir=/data/3399
恢复：
（2） 准备过程
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399_bk/my3399.cnf --prepare --target_dir=/data/3399
再执行一次：
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399_bk/my3399.cnf --prepare --target_dir=/data/3399
注意：
从备份到恢复会经过3个步骤：backup→prepare→restore 在prepare之前，数据文件是不一致的，因为它们在不同时间点被备份因此，--prepare会使所有数据文件的步调达成一致
这个prepare过程你可以在任何机器上运行，没有强制在线上或者备份库上运行, 你可以把备份复制到闲置的服务器上去运行prepare，以此来降低备份库的压力,不过，你必须保证backup和prepare所使用的xtrabackup的版本要一致.
在prepare过程中，xtrabackup会启动一个内置的改良的InnoDB，运用备份的日志在备份的数据文件上进行崩溃恢复
比如：xtrabackup --prepare --target-dir=/data/backups/mysql/
prepare完成后会有如下类似输出：
101107 16:40:15 InnoDB: Shutdown completed; log sequence number <LSN> 那么此时你的所有数据文件才算全部一致，也才算得上是一份有效的备份
但是或者可能想要去加快恢复时间，很简单，只要再次运行一次prepare，第二次运行prepare，xtrabackup会创建一份日志文件，为我们在restore时节省恢复时间
在prepare过程，建议不能因为计划内或计划外将其中断，这会导致数据文件损坏，备份的有效性将不能得到保证。
（3） 恢复过程
拷贝所有文件到datadir:
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399_bk/my3399.cnf --copy-back --target_dir=/data/3399
以下为恢复过程：
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399_bk/my3399.cnf --prepare --target_dir=/data/3399
xtrabackup: recognized server arguments: --datadir=/data/mydata/my3399 --tmpdir=/data/mydata/my3399 --server-id=212193399 --open_files_limit=8192 --innodb_data_home_dir=/data/mydata/my3399 --innodb_log_group_home_dir=/data/mydata/my3399 --innodb_buffer_pool_size=5G --innodb_data_file_path=ibdata1:1G;ibdata2:1G:autoextend --innodb_file_per_table=1 --innodb_flush_log_at_trx_commit=1 --innodb_io_capacity=2000 --innodb_log_buffer_size=64M --innodb_log_files_in_group=3 --innodb_log_file_size=1000M --innodb_read_io_threads=12 --innodb_write_io_threads=12 --innodb_flush_method=O_DIRECT --innodb_undo_tablespaces=4 --log_bin=/data/mydata/my3399/mysql-bin
xtrabackup: recognized client arguments: --datadir=/data/mydata/my3399 --tmpdir=/data/mydata/my3399 --server-id=212193399 --open_files_limit=8192 --innodb_data_home_dir=/data/mydata/my3399 --innodb_log_group_home_dir=/data/mydata/my3399 --innodb_buffer_pool_size=5G --innodb_data_file_path=ibdata1:1G;ibdata2:1G:autoextend --innodb_file_per_table=1 --innodb_flush_log_at_trx_commit=1 --innodb_io_capacity=2000 --innodb_log_buffer_size=64M --innodb_log_files_in_group=3 --innodb_log_file_size=1000M --innodb_read_io_threads=12 --innodb_write_io_threads=12 --innodb_flush_method=O_DIRECT --innodb_undo_tablespaces=4 --log_bin=/data/mydata/my3399/mysql-bin --prepare=1 --target-dir=/data/3399
xtrabackup version 8.0.1 based on MySQL server 8.0.11 Linux (x86_64) (revision id: )
xtrabackup: cd to data/3399/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=9437184, start_lsn=(17123932598)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 9437184
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 9437184
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Directories to scan '.;.;.'
InnoDB: Scanning './'
InnoDB: Completed space ID check of 16 files.
InnoDB: Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: The log sequence number 13488191 in the system tablespace does not match the log sequence number 17123932598 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Starting to parse redo log at lsn = 17123932228, whereas checkpoint_lsn = 17123932598
InnoDB: Doing recovery: scanned up to log sequence number 17123932598
InnoDB: Log background threads are being started...
InnoDB: Applying a batch of 0 redo log records ...
InnoDB: Apply batch completed!
InnoDB: xtrabackup: Last MySQL binlog file position 323154864, file name mysql-bin.000017
InnoDB: Opened 4 existing undo tablespaces.
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
InnoDB: 8.0.11 started; log sequence number 17123932598
Populating InnoDB table cache.
InnoDB: Allocated tablespace ID 4 for sbtest/sbtest1, old maximum was 0
InnoDB: Loading buffer pool(s) from data/3399/(null)
InnoDB: Cannot open '/data/3399/(null)' for reading: No such file or directory
InnoDB: xtrabackup: Last MySQL binlog file position 323154864, file name mysql-bin.000017
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Dumping buffer pool(s) to data/3399/(null)
InnoDB: Buffer pool(s) dump completed at 180914 16:30:10
InnoDB: Log background threads are being closed...
InnoDB: Shutdown completed; log sequence number 17123932598
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1048576000
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Directories to scan '.;.;.'
InnoDB: Scanning './'
InnoDB: Completed space ID check of 16 files.
InnoDB: Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: Setting log file ./ib_logfile101 size to 16384000 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000
InnoDB: Setting log file ./ib_logfile1 size to 16384000 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000
InnoDB: Setting log file ./ib_logfile2 size to 16384000 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=17123932684
InnoDB: Log background threads are being started...
InnoDB: Applying a batch of 0 redo log records ...
InnoDB: Apply batch completed!
InnoDB: Opened 4 existing undo tablespaces.
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
InnoDB: Page cleaner took 6038ms to flush 0 and evict 0 pages
InnoDB: 8.0.11 started; log sequence number 17123932684
InnoDB: Loading buffer pool(s) from data/3399/(null)
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Buffer pool(s) load completed at 180914 16:30:17
InnoDB: Dumping buffer pool(s) to data/3399/(null)
InnoDB: Buffer pool(s) dump completed at 180914 16:30:17
InnoDB: Log background threads are being closed...
InnoDB: Shutdown completed; log sequence number 17123932684
180914 16:30:19 completed OK!
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399_bk/my3399.cnf --prepare --target_dir=/data/3399
xtrabackup: recognized server arguments: --datadir=/data/mydata/my3399 --tmpdir=/data/mydata/my3399 --server-id=212193399 --open_files_limit=8192 --innodb_data_home_dir=/data/mydata/my3399 --innodb_log_group_home_dir=/data/mydata/my3399 --innodb_buffer_pool_size=5G --innodb_data_file_path=ibdata1:1G;ibdata2:1G:autoextend --innodb_file_per_table=1 --innodb_flush_log_at_trx_commit=1 --innodb_io_capacity=2000 --innodb_log_buffer_size=64M --innodb_log_files_in_group=3 --innodb_log_file_size=1000M --innodb_read_io_threads=12 --innodb_write_io_threads=12 --innodb_flush_method=O_DIRECT --innodb_undo_tablespaces=4 --log_bin=/data/mydata/my3399/mysql-bin
xtrabackup: recognized client arguments: --datadir=/data/mydata/my3399 --tmpdir=/data/mydata/my3399 --server-id=212193399 --open_files_limit=8192 --innodb_data_home_dir=/data/mydata/my3399 --innodb_log_group_home_dir=/data/mydata/my3399 --innodb_buffer_pool_size=5G --innodb_data_file_path=ibdata1:1G;ibdata2:1G:autoextend --innodb_file_per_table=1 --innodb_flush_log_at_trx_commit=1 --innodb_io_capacity=2000 --innodb_log_buffer_size=64M --innodb_log_files_in_group=3 --innodb_log_file_size=1000M --innodb_read_io_threads=12 --innodb_write_io_threads=12 --innodb_flush_method=O_DIRECT --innodb_undo_tablespaces=4 --log_bin=/data/mydata/my3399/mysql-bin --prepare=1 --target-dir=/data/3399
xtrabackup version 8.0.1 based on MySQL server 8.0.11 Linux (x86_64) (revision id: )
xtrabackup: cd to data/3399/
xtrabackup: This target seems to be already prepared.
InnoDB: Number of pools: 1
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1048576000
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1048576000
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Directories to scan '.;.;.'
InnoDB: Scanning './'
InnoDB: Completed space ID check of 16 files.
InnoDB: Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: Log background threads are being started...
InnoDB: Applying a batch of 0 redo log records ...
InnoDB: Apply batch completed!
InnoDB: Opened 4 existing undo tablespaces.
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
InnoDB: 8.0.11 started; log sequence number 17123932684
Populating InnoDB table cache.
InnoDB: Allocated tablespace ID 4 for sbtest/sbtest1, old maximum was 0
InnoDB: Loading buffer pool(s) from data/3399/(null)
InnoDB: Buffer pool(s) load completed at 180914 16:31:22
InnoDB: xtrabackup: Last MySQL binlog file position 323154864, file name mysql-bin.000017
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Dumping buffer pool(s) to /data/3399/(null)
InnoDB: Buffer pool(s) dump completed at 180914 16:31:22
InnoDB: Log background threads are being closed...
InnoDB: Shutdown completed; log sequence number 17123932684
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:1G;ibdata2:1G:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1048576000
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.7
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Directories to scan '.;.;.'
InnoDB: Scanning './'
InnoDB: Completed space ID check of 16 files.
InnoDB: Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: page_cleaner worker priority: -20
InnoDB: Log background threads are being started...
InnoDB: Applying a batch of 0 redo log records ...
InnoDB: Apply batch completed!
InnoDB: Opened 4 existing undo tablespaces.
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
InnoDB: 8.0.11 started; log sequence number 17123932684
InnoDB: Loading buffer pool(s) from /data/3399/(null)
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Buffer pool(s) load completed at 180914 16:31:24
InnoDB: Starting shutdown...
InnoDB: Dumping buffer pool(s) to /data/3399/(null)
InnoDB: Buffer pool(s) dump completed at 180914 16:31:24
InnoDB: Log background threads are being closed...
InnoDB: Shutdown completed; log sequence number 17123932684
180914 16:31:25 completed OK!
6.2 Xtrabackup实现增及恢复
原理：
（1）首先进行0级备份，记录此时LSN。0级备份完，xtrabackup会在备份保存点下的xtrabackup_checkpoints文件里记录一个to_lsn值，该值是备份结束后全库的LSN
（2）当进行1级备份时，比较表空间中每个页的LSN是否大于0级备份的LSN，如果是，则备份该页，并记录当前的LSN
（1） 首先进行全备（0级备份）
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --backup --target-dir=/data/3399full
（2） 进行第一次增量备份（1级备份）
[root@sjs_21_219 mysql]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --backup --incremental-basedir=/data/3399full --target-dir=/data/3399_bak1
（3） 进行第二次增量备份
[root@sjs_21_219 mysql]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --backup --incremental-basedir=/data/3399full --target-dir=/data/3399_bak2
（4） 准备过程（恢复过程）
准备过程和innobackupex是一样的，使用"--apply-log-only"来直线向前地应用redo log，
同样，在最后一个增备集的准备过程中不能使用"--apply-log-only"选项
在--prepare阶段，增量备份和普通的备份存在差异，对于普通的备份，已提交的事务通过备份的数据文件利用日志中的变化信息去重演这个变化的过程，而未提交的会被回滚
对于增量备份，在--prepare阶段，必须跳过未提交事务的回滚，因为它们在下一次增量备份时可能会被提交
所以，应该使用--apply-log-only来阻止未提交事务的回滚，如果你不那么做的话，增量备份可能会变成无效，若是事务被回滚掉，则下一次的增量备份将无法应用。
恢复基础备份（全备）：
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --prepare --apply-log-only --target-dir=/data/3399full
恢复增量备份到基础备份（开始恢复增量备份要添加—redo-only参数，到最后一次增量备份去掉—redo-only参数）：
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock –prepare --apply-log-only --target-dir=/data/3399full --incremental-dir=/data/3399_bak1
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock –prepare --target-dir=/data/3399full --incremental-dir=/data/3399_bak2
对整体的基础备份进行恢复，回滚那些没有提交的数据：
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --prepare --target-dir=/data/3399full
（5） Copy或修改权限过程
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399_bk/my3399.cnf --copy-back --target_dir=/data/3399full
6.3 xtrabackup实现指定表备份
和innobackupex一样，用--databases=dbname.tablename和--tables-file，也可以用--tables（--include），支持正则。
如备份it开头的数据库下的所有表：
[root@sjs_21_219 ~]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock --datadir=/data/mydata/my3399/ --backup --parallel=3 --tables="^it[.]*.*" --target-dir=/data/ittab
6.4 xtrabackup不完全恢复
由于误操作，比如删除了一张表，这时使用完全恢复是没有用的，需要恢复到误操作之前的状态，然后跳过错误操作语句，再恢复后面执行的语句。主要有基于时间和基于位置的恢复。
例如，20180927上午12:00时候误删除了一张表，这时候我们可以进行基于时间点恢
复和基于位置的不完全恢复。
（1） 找出备份时刻binlog的名称和位置
首先找到最近的一份全备份：/data/3399full
找到记录备份结束时刻的binglog的位置文件xtrabackup_binlog_info，查看备份时刻binlog的名称和位置
（2） 查看当前数据库的binlog文件和位置
（3） 从全备中恢复数据库
[root@sjs_21_219 mysql]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --prepare --target_dir=/data/3399full
（4） 从全备结束时刻binlog位置开始，恢复到误操作时刻12:00之前的binlog.
[root@sjs_21_219 mysql]# bin/mysqlbinlog --start-position="14258517" --stop-datetime="2018-09-27 11:59:59" /data/mydata/my3399/mysql-bin.000002 /data/mydata/my3399/mysql-bin.000002
（5） 跳过故障点的误操作的时间点，应用之后所有的binlog文件
[root@sjs_21_219 mysql]# bin/mysqlbinlog --start-position="14258517" --stop-datetime="2018-09-27 11:59:59" /data/mydata/my3399/mysql-bin.000002 /data/mydata/my3399/mysql-bin.000002
6.5 Xtrabackup克隆slave（备库备份）
克隆slave时，常用参数--slave-info和--safe-slave-backup
--slave-info:会将master的binary log的文件名和偏移量位置保存到xtrabackup_slave_info
文件中。
--safe-slave-backup会暂停slave的SQL线程，直到没有打开临时表的时候开始备份，待
备份结束后会自动启动，目的是为了确保一致性的复制状态。
[root@sjs_21_219 mysql]# xtrabackup --defaults-file=/data/mydata/my3399/my3399.cnf --user=root --port=3399 --host=10.144.21.219 --socket=/tmp/mysql3399.sock –parallel=5 --backup --slave-info --safe-slave-backup --target-dir=/data/3399slave
