用XtraBackup备份时报错又一个错误，这是啥原因
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了用XtraBackup备份时报错又一个错误，这是啥原因相关的知识，希望对你有一定的参考价值。
Xtrabackup 是由 percona 开源的免费数据库热备份软件，它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。
为了方便建立从库，Xtrabackup 在备份完成后会将 binlog position 与 GTID 的相关信息保存于 xtrabackup_binlog_info 文件中。但是当你使用 Xtrabackup 生成的备份建立一个从库时，会发现恢复后的实例执行 show master status，显示的 Executed_Gtid_Set 与 xtrabackup_binlog_info 文件中记录的信息并不一致，而且使用 Xtrabackup 2.4 与 8.0（对 mysql 8.0 进行备份）生成的备份在恢复后，信息不一致的表现又不相同。本篇文章主要针对该现象进行简单的分析。一、Xtrabackup 2.4.18 for MySQL 5.7.26
现象
1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：\\# cat xtrabackup_binlog_infomysql-bin.000003 86412752 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-5958592. 将该备份恢复至一个新实例并启动该实例，执行 show master status; 查看信息：mysql> show master status\\G*************************** 1. row *************************** File: mysql-bin.000001 Position: 154 Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-3266611 row in set (0.00 sec)此时会发现使用备份恢复的实例显示已执行过的 GTID 是 1-326661，而备份文件显示的是 1-595859，这是否表示两者相差的 GTID:326662-595859 代表的事务丢失了？通过对原实例（进行备份的实例）的 binlog 进行解析，来查询 GTID:326662-595859 这部分事务所生成的数据在新实例（通过备份恢复的实例）上是否存在。可以发现 GTID:326662-595859 这部分事务的数据都存在于新实例上，也就是说数据与 xtrabackup_binlog_info 文件记录的是一致的，只不过与 show master status 命令获取的信息的不一致。
原因分析
首先我们要清楚 Xtrabackup 2.4 的备份流程，大致如下：
1. start backup
2. copy ibdata1 / copy .ibd file
3. Excuted ftwrl
4. backup non-InnoDB tables and files
5. Writing xtrabackup_binlog_info
6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
7. Executed UNLOCK TABLES
8. Copying ib_buffer_pool
9. completed OK!
结合备份时的 general log 可知，Xtrabackup 在执行 ftwrl 并备份完所有非 InnoDB 表格的文件后通过 show master status 获取了 binlog position 和 GTID 的信息，将其记录到 xtrabackup_binlog_info 文件中。
那么 show master status 获取的是哪些信息？
该命令提供本实例的 binlog 文件的状态信息，显示正在写入的 binlog 文件，以及当前的binlog position，并且 MySQL 5.7 在 MySQL 库下引入了 gtid_executed 表，该表会记录当前执行过的 GTID。
那么目前看来问题可能就出在 gtid_executed 表格上，通过测试和官方文档提供的信息可知，该表格虽然是 InnoDB 表，但是其中的数据并非是实时更新的，且该表格记录信息的方式存在以下两个情况：1. 如果禁用了 log_bin，实例不会在该表格记录任何信息；若从库的 log_slave_updates 为 OFF，那么从库会在应用 relay-log 中的每个事务时执行一次 insert mysql.gtid_executed 的操作。2. 如果启用了 log_bin，则该表格记录的是在 binlog 发生切换（rotate）的时候直到上一个 binlog 文件执行过的全部 GTID，而此时 show master status 获取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系统变量 gtid_exected 提供；如果服务器意外停止，则当前 binlog 文件中的 Gtid 集合不会保存在 mysql.gtid_executed 表中，在实例恢复期间，这些 Gtid 从 binlog 文件中读取并添加到表中。
小结
所以当备份恢复时，实际 show master status 可能会出现以下情况：1. 当 log_bin 禁用或者 log_slave_updates 为 OFF 时，备份恢复后的实例 show master status 显示为空。2. 当开启了 log_bin，但是该实例并未发生过 binlog 的切换时，备份恢复后的实例 show master status 显示也为空。3. 当开启了 log_bin，其该实例的 binlog 发生过切换时，备份恢复后的实例 show master status 显示的信息会比 xtrabackup_binlog_info 文件中记录的 GTID 缺失一部分，这一部分就是 mysql.gtid_executed 表格未记录的部分。二、Xtrabackup 8.0.8 for MySQL 8.0.18现象1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：# # cat xtrabackup_binlog_infobinlog.000033 1459 70ec927f-4c6d-11ea-b88c-02000aba3fb1:1-6216832. 查看备份实例相对应的 binlog 解析后的内容：
# mysqlbinlog -vv binlog.000033 | less
定位至 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683
# at 508
#200213 13:46:47 server id 663728 end_log_pos 583 GTID last_committed=0 sequence_number=2 rbr_only=yes original_committed_timestamp=1581572807720907 immediate_commit_timestamp=15815728
07720907 transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)
# immediate_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)
/*!80001 SET @@session.original_commit_timestamp=1581572807720907*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683'/*!*/;
# at 583
#200213 13:46:47 server id 663728 end_log_pos 659 Query thread_id=214 exec_time=0 error_code=0
SET TIMESTAMP=1581572807/*!*/;
BEGIN
/*!*/;
# at 659
#200213 13:46:47 server id 663728 end_log_pos 708 Rows_query
# insert into t1 values(null,2)
# at 708
#200213 13:46:47 server id 663728 end_log_pos 758 Table_map: `mysqlslap`.`t1` mapped to number 314
# at 758
#200213 13:46:47 server id 663728 end_log_pos 798 Write_rows: table id 314 flags: STMT_END_F
BINLOG '
x+JEXh2wIAoAMQAAAMQCAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVsbCwyKQ==
x+JEXhOwIAoAMgAAAPYCAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAB4DAAAAADoBAAAAAAEAAgAC/wCKAAEAAgAAAA==
'/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65674 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 798
#200213 13:46:47 server id 663728 end_log_pos 825 Xid = 2436045
COMMIT/*!*/;
可以发现该文件提供的 binlog position 与 GTID 并不对应。而 binlog.000033:1459 对应的 GTID 是 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685 提交后的下一个位置：
# at 1142
#200213 13:46:47 server id 663728 end_log_pos 1217 GTID last_committed=2 sequence_number=4 rbr_only=yes original_committed_timestamp=1581572807724646 immediate_commit_timestamp=15815728
07724646 transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)
# immediate_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)
/*!80001 SET @@session.original_commit_timestamp=1581572807724646*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685'/*!*/;
# at 1217
#200213 13:46:47 server id 663728 end_log_pos 1293 Query thread_id=215 exec_time=0 error_code=0
SET TIMESTAMP=1581572807/*!*/;
BEGIN
/*!*/;
# at 1293
#200213 13:46:47 server id 663728 end_log_pos 1342 Rows_query
# insert into t1 values(null,2)
# at 1342
#200213 13:46:47 server id 663728 end_log_pos 1392 Table_map: `mysqlslap`.`t1` mapped to number 314
# at 1392
#200213 13:46:47 server id 663728 end_log_pos 1432 Write_rows: table id 314 flags: STMT_END_F
BINLOG '
x+JEXh2wIAoAMQAAAD4FAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVsbCwyKQ==
x+JEXhOwIAoAMgAAAHAFAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAJgFAAAAADoBAAAAAAEAAgAC/wCMAAEAAgAAAA==
'/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65676 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 1432
#200213 13:46:47 server id 663728 end_log_pos 1459 Xid = 2436047
COMMIT/*!*/;
# at 1459
3. 再看将备份恢复到一个新实例并启动后，执行 show master status 显示的信息：mysql> show master status\\G*************************** 1. row *************************** File: binlog.000034 Position: 191 Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 70ec927f-4c6d-11ea-b88c-02000aba3fb1:1-6216851 row in set (0.00 sec)
可以发现与 Xtrabackup 2.4 不同的是，该备份的 xtrabackup_binlog_info 文件记录的信息并不准确，而备份恢复后显示的信息却是准确的。
原因
首先我们来看一下 Xtrabackup 8.0 针对 MySQL 8.0 备份的大致过程：1. start backup2. copy .ibd file3. backup non-InnoDB tables and files4. Executed FLUSH NO_WRITE_TO_BINLOG BINARY LOGS5. Selecting LSN and binary log position from p_s.log_status6. copy last binlog file7. Writing /mysql/backup/backup/binlog.index8. Writing xtrabackup_binlog_info9. Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS10. copy ib_buffer_pool11. completed OK!由以上步骤可知，Xtrabackup 8.0 对 MySQL 8.0 的备份与 Xtrabackup 2.4 略有不同，根据 percona 官方文档的信息，当 MySQL 8.0 中仅存在 InnoDB 引擎的表格时，不再执行ftwrl（当存在非 InnoDB 的表格或者使用 --slave-info 选项时会执行），而是根据上述步骤的第 5 步，Xtrabackup 8.0 会通过SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status
来获取 LSN 、binlog position and Gtid。1. performance_schema.log_status 是 MySQL 8.0 提供给在线备份工具获取复制日志文件信息的表格。查询 log_status 表时，服务器将阻止日志的记录和相关的更改来获取足够的时间以填充该表，然后释放资源。Log_status 表通知在线备份工具应记录主库的 binlog 的哪个位点和 gtid_executed 的值，还有每个复制通道的 relay log。它还为各个存储引擎提供了相关信息，例如 InnoDB 存储引擎使用的最后一个日志序列号（LSN）和最后一个检查点的 LSN。2. 经过测试发现，当无数据写入时， performance_schema.log_status 提供的 binlog position 与 GTID 是一致的，但是当有大量数据持续写入时，该表格提供的 binlog position 与 GTID 信息将不再一致，如下图：
3. 既然 performance_schema.log_status 提供的信息不一致，那么为什么备份恢复后，GTID 没有缺失？这是因为 Xtrabackup 8.0 在备份过程中多了两步操作，FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 和 copy binlog，Xtrabackup 8.0 在备份完非 InnoDB 表格的文件时会先切换 binlog，然后将切换后的 binlog 也进行备份，这样使用该备份恢复的新实例在启动后不仅会读取 gtid_executed 表，也会读取 binlog 文件来更新 GTID，就可以保持与备份时 xtrabackup_binlog_info 文件记录的 binlog position 保持一致（需要注意的是 MySQL 8.0 的 gtid_executed 表格不再是当 binlog 切换时更新，而是会不断的实时更新，但需要注意在有大量数据写入时也不能做到和全局变量 gtid_exeuted 保持严格一致）。4. 当 MySQL 8.0 中存在非 InnoDB 的表格，比如 MyISAM 表时，Xtrabackup 8.0 会在执行完 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 后执行 ftwrl，此时查询 performance_schema.log_status 得到的 binlog position 与 GTID 是一致的，且备份恢复后 show master status 显示的信息也与 xtrabackup_binlog_info 文件记录的信息一致。
总结1. Xtrabackup 2.4 备份后生成的 xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，但是备份恢复后 show master status 显示的 GTID 是不准确的。2. Xtrabackup 8.0 在备份只有 InnoDB 表的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息不一定是准确的，但是备份恢复后 show master status 显示的 GTID 是准确的。3. Xtrabackup 8.0 在备份有非 InnoDB 表格的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，备份恢复后 show master status 显示的 GTID 也是准确的。
注意：此处的“准确”主要指 xtrabackup_binlog_info 文件中记录的 GTID 与备份中实际的 binlog position & 数据是否一致。
请点击输入图片描述
mysql备份实战-Xtrabackup工具备份
| 导读 | 大数据量备份与还原，始终是个难点。当MYSQL超10G，用mysqldump来导出就比较慢了。这里介绍一个强大的开源工具Xtrabackup。 |
Xtrabackup简介
Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具，是商业备份工具InnoDB Hotbackup的一个很好的替代品。特点：
(1)备份过程快速、可靠； (2)备份过程不会打断正在执行的事务； (3)能够基于压缩等功能节约磁盘空间和流量； (4)自动实现备份检验； (5)还原速度快；
Xtrabackup安装
其最新版的软件可从 http://www.percona.com/software/percona-xtrabackup/ 获得。本文基于CentOS6.6的系统，因此，直接下载相应版本的rpm包安装即可。
[[email protected] xtrabackup]# yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL //安装依赖包
[[email protected] xtrabackup]# rpm -ivh percona-xtrabackup-2.2.4-5004.el6.x86_64.rpm warning: percona-xtrabackup-2.2.4-5004.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY Preparing... ########################################### [100%] 1:percona-xtrabackup ########################################### [100%]
Xtrabackup备份的实现
1、完全备份
# innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
如果要使用一个最小权限的用户进行备份，则可基于如下命令创建此类用户：
mysql> CREATE USER ’feiyu‘@’localhost’ IDENTIFIED BY ’s3cret’; mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM ’feiyu’; mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ’feiyu’@’localhost’; mysql> FLUSH PRIVILEGES;
使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命令的目录中。
在备份的同时，innobackupex还会在备份目录中创建如下文件：
(1)xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；
每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。
(2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
(3)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。
(4)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；
(5)backup-my.cnf —— 备份命令用到的配置选项信息；
在使用innobackupex进行备份时，还可以使用–no-timestamp选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。
2、准备(prepare)一个完全备份
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
innobakupex命令的–apply-log选项可用于实现上述功能。如下面的命令：
# innobackupex --apply-log /path/to/BACKUP-DIR
如果执行正确，其最后输出的几行信息通常如下：
xtrabackup: starting shutdown with innodb_fast_shutdown = 1 120407 9:01:36 InnoDB: Starting shutdown... 120407 9:01:40 InnoDB: Shutdown completed; log sequence number 92036620 120407 09:01:40 innobackupex: completed OK!
在实现“准备”的过程中，innobackupex通常还可以使用–use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。
3、从一个完全备份中恢复数据
innobackupex命令的–copy-back选项用于执行恢复操作，其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。
# innobackupex --copy-back /path/to/BACKUP-DIR
如果执行正确，其输出信息的最后几行通常如下：
innobackupex: Starting to copy InnoDB log files innobackupex: in ‘/backup/2012-04-07_08-17-03‘ innobackupex: back to original InnoDB log directory ‘/mydata/data‘ innobackupex: Finished copying back files. 120407 09:36:10 innobackupex: completed OK!
请确保如上信息的最行一行出现“innobackupex: completed OK!”。
当数据恢复至DATADIR目录以后，还需要确保所有数据文件的属主和属组均为正确的用户，如mysql，否则，在启动mysqld之前还需要事先修改数据文件的属主和属组。如：
# chown -R mysql:mysql /mydata/data/
4、使用innobackupex进行增量备份
每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。
要实现第一次增量备份，可以使用下面的命令进行：
# innobackupex --incremental /backup --incremental-basedir=BASEDIR
（要对与完全备份实行增量备份，basedir指完全备份的目录，要对上一次增量备份再执行增量备份，则指定上一次
增量备份的目录）
其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其–incremental-basedir应该指向上一次的增量备份所在的目录。
需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。
“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：
(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。
(2)基于所有的备份将未提交的事务进行“回滚”。
（以下为合并增量备份到完全备份，然后恢复时只指定完全备份即可）
于是，操作就变成了：
# innobackupex --apply-log --redo-only BASE-DIR
接着执行：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
而后是第二个增量：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
其中BASE-DIR指的是完全备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即如果有多次增量备份，每一次都要执行如上操作；
5、Xtrabackup的“流”及“备份压缩”功能
Xtrabackup对备份的数据文件支持“流”功能，即可以将备份的数据通过STDOUT传输给tar程序进行归档，而不是默认的直接保存至某备份目录中。要使用此功能，仅需要使用–stream选项即可。如：
# innobackupex --stream=tar /backup | gzip > /backup/`date +%F_%H-%M-%S`.tar.gz
甚至也可以使用类似如下命令将数据备份至其它服务器：
# innobackupex --stream=tar /backup | ssh [email protected] "cat - > /backups/`date +%F_%H-%M-%S`.tar"
此外，在执行本地备份时，还可以使用–parallel选项对多个文件进行并行复制。此选项用于指定在复制时启动的线程数目。当然，在实际进行备份时要利用此功能的便利性，也需要启用innodb_file_per_table选项或共享的表空间通过innodb_data_file_path选项存储在多个ibdata文件中。对某一数据库的多个文件的复制无法利用到此功能。其简单使用方法如下：
# innobackupex --parallel /path/to/backup
同时，innobackupex备份的数据文件也可以存储至远程主机，这可以使用–remote-host选项来实现：
# innobackupex [email protected] /path/IN/REMOTE/HOST/to/backup
6、导入或导出单张表
默认情况下，InnoDB表不能通过直接复制表文件的方式在mysql服务器之间进行移植，即便使用了innodb_file_per_table选项。而使用Xtrabackup工具可以实现此种功能，不过，此时需要“导出”表的mysql服务器启用了innodb_file_per_table选项（严格来说，是要“导出”的表在其创建之前，mysql服务器就启用了innodb_file_per_table选项），并且“导入”表的服务器同时启用了innodb_file_per_table和innodb_expand_import选项。
(1)“导出”表
导出表是在备份的prepare阶段进行的，因此，一旦完全备份完成，就可以在prepare过程中通过–export选项将某表导出了：
# innobackupex --apply-log --export /path/to/backup
此命令会为每个innodb表的表空间创建一个以.exp结尾的文件，这些以.exp结尾的文件则可以用于导入至其它服务器。
(2)“导入”表
要在mysql服务器上导入来自于其它服务器的某innodb表，需要先在当前服务器上创建一个跟原表表结构一致的表，而后才能实现将表导入：
mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;
然后将此表的表空间删除：
mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
接下来，将来自于“导出”表的服务器的mytable表的mytable.ibd和mytable.exp文件复制到当前服务器的数据目录，然后使用如下命令将其“导入”：
mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
7、使用Xtrabackup对数据库进行部分备份
Xtrabackup也可以实现部分备份，即只备份某个或某些指定的数据库或某数据库中的某个或某些表。但要使用此功能，必须启用innodb_file_per_table选项，即每张表保存为一个独立的文件。同时，其也不支持–stream选项，即不支持将数据通过管道传输给其它程序进行处理。
此外，还原部分备份跟还原全部数据的备份也有所不同，即你不能通过简单地将prepared的部分备份使用–copy-back选项直接复制回数据目录，而是要通过导入表的方向来实现还原。当然，有些情况下，部分备份也可以直接通过–copy-back进行还原，但这种方式还原而来的数据多数会产生数据不一致的问题，因此，无论如何不推荐使用这种方式。
(1)创建部分备份
创建部分备份的方式有三种：正则表达式(–include), 枚举表文件(–tables-file)和列出要备份的数据库(–databases)。
(a)使用–include
使用–include时，要求为其指定要备份的表的完整名称，即形如databasename.tablename，如：
# innobackupex --include=‘^feiyu[.]tb1‘ /path/to/backup
(b)使用–tables-file
此选项的参数需要是一个文件名，此文件中每行包含一个要备份的表的完整名称；如：
# echo -e ‘feiyu.tb1\nmageedu.tb2‘ > /tmp/tables.txt # innobackupex --tables-file=/tmp/tables.txt /path/to/backup
(c)使用–databases
此选项接受的参数为数据名，如果要指定多个数据库，彼此间需要以空格隔开；同时，在指定某数据库时，也可以只指定其中的某张表。此外，此选项也可以接受一个文件为参数，文件中每一行为一个要备份的对象。如：
# innobackupex --databases="feiyu testdb" /path/to/backup
(2)整理(preparing)部分备份
prepare部分备份的过程类似于导出表的过程，要使用–export选项进行：
# innobackupex --apply-log --export /pat/to/partial/backup
此命令执行过程中，innobackupex会调用xtrabackup命令从数据字典中移除缺失的表，因此，会显示出许多关于“表不存在”类的警告信息。同时，也会显示出为备份文件中存在的表创建.exp文件的相关信息。
(3)还原部分备份
还原部分备份的过程跟导入表的过程相同。当然，也可以通过直接复制prepared状态的备份直接至数据目录中实现还原，不要此时要求数据目录处于一致状态。
下面实际演示其完整的备份流程：
←#14#[email protected] /tmp/full-backup →innobackupex --user=root /tmp/full-backup/ #完全备份 InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. 。。。。。。。。。。 xtrabackup: The latest check point (for incremental): ‘2987626‘ xtrabackup: Stopping log copying thread. .>> log scanned up to (2987626) xtrabackup: Creating suspend file ‘/tmp/full-backup/2015-06-25_05-58-26/xtrabackup_log_copied‘ with pid ‘7858‘ xtrabackup: Transaction log of lsn (2987626) to (2987626) was copied. 150625 05:58:30 innobackupex: All tables unlocked innobackupex: Backup created in directory ‘/tmp/full-backup/2015-06-25_05-58-26‘ innobackupex: MySQL binlog position: filename ‘mysql-bin.000001‘, position 2383 150625 05:58:30 innobackupex: Connection to database server closed 150625 05:58:30 innobackupex: completed OK!
mysql> insert into tutors(tname) values(‘stu00011‘);#在数据库中插入数据 Query OK, 1 row affected (0.03 sec) mysql> insert into tutors(tname) values(‘stu00012‘); Query OK, 1 row affected (0.00 sec)
←#246#[email protected] /tmp →innobackupex --incremental /tmp/full-backup/ --incremental-basedir=/tmp/full-backup/2015-06-25_05-58-26/ #做增量备份 InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. 。。。。。。。。。。。 xtrabackup: Creating suspend file ‘/tmp/full-backup/2015-06-25_06-00-48/xtrabackup_log_copied‘ with pid ‘8663‘ xtrabackup: Transaction log of lsn (2988209) to (2988209) was copied. 150625 06:00:53 innobackupex: All tables unlocked innobackupex: Backup created in directory ‘/tmp/full-backup/2015-06-25_06-00-48‘ innobackupex: MySQL binlog position: filename ‘mysql-bin.000001‘, position 2924 150625 06:00:53 innobackupex: Connection to database server closed 150625 06:00:53 innobackupex: completed OK!
mysql> insert into tutors(tname) values(‘stu00014‘); #再次插入数据 Query OK, 1 row affected (0.02 sec) mysql> insert into tutors(tname) values(‘stu00015‘); Query OK, 1 row affected (0.00 sec)
←#247#[email protected] /tmp →innobackupex --incremental /tmp/full-backup/ --incremental-basedir=/tmp/full-backup/2015-06-25_06-00-48 #再次做增量备份 InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved 。。。。。。。。。 xtrabackup: Creating suspend file ‘/tmp/full-backup/2015-06-25_06-02-41/xtrabackup_log_copied‘ with pid ‘9259‘ xtrabackup: Transaction log of lsn (2988781) to (2988781) was copied. 150625 06:02:45 innobackupex: All tables unlocked innobackupex: Backup created in directory ‘/tmp/full-backup/2015-06-25_06-02-41‘ innobackupex: MySQL binlog position: filename ‘mysql-bin.000001‘, position 3465 150625 06:02:46 innobackupex: Connection to database server closed 150625 06:02:46 innobackupex: completed OK!
←#266#[email protected] /tmp/full-backup/2015-06-25_05-58-26 →cat xtrabackup_checkpoints #查看日志序列号是否一致 backup_type = log-applied from_lsn = 0 to_lsn = 2987626 last_lsn = 2987626 compact = 0 ←#267#[email protected] /tmp/full-backup/2015-06-25_05-58-26 →cd ../2015-06-25_06-00-48/ ←#268#[email protected] /tmp/full-backup/2015-06-25_06-00-48 →cat xtrabackup_checkpoints backup_type = incremental from_lsn = 2987626 to_lsn = 2988209 last_lsn = 2988209 compact = 0 ←#269#[email protected] /tmp/full-backup/2015-06-25_06-00-48 →cd ../2015-06-25_06-02-41/ ←#270#[email protected] /tmp/full-backup/2015-06-25_06-02-41 →cat xtrabackup_checkpoints backup_type = incremental from_lsn = 2988209 to_lsn = 2988781 last_lsn = 2988781 compact = 0
←#248#[email protected] /tmp →innobackupex --apply-log --redo-only /tmp/full-backu2015-06-25_05-58-26/ #做准备 InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. [notice (again)] If you use binary log and don‘t use any hack of group commit, the binary log position seems to be: InnoDB: Last MySQL binlog file position 0 2241, file name ./mysql-bin.000001 xtrabackup: starting shutdown with innodb_fast_shutdown = 1 InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 2987626 150625 06:04:03 innobackupex: completed OK! ←#249#[email protected] /tmp →innobackupex --apply-log --redo-only /tmp/full-backu2015-06-25_05-58-26/ --incremental-dir=/tmp/full-backup/2015-06-25_06-00-48/ #合并第一次增量备份文件 。。。。。。。。。。 innobackupex: Copying ‘/tmp/full-backup/2015-06-25_06-00-48/management/admin.frm‘ to ‘/tmp/full-backup/2015-06-25_05-58-26/management/admin.frm‘ 150625 06:05:28 innobackupex: completed OK! ←#251#[email protected] /tmp →innobackupex --apply-log --redo-only /tmp/full-backu2015-06-25_05-58-26/ --incremental-dir=/tmp/full-backup/2015-06-25_06-02-41/ #合并第二次增量备份文件 。。。。。。。。。。。。。。。。 innobackupex: Copying ‘/tmp/full-backup/2015-06-25_06-02-41/management/classinfo.frm‘ to ‘/tmp/full-backup/2015-06-25_05-58-26/management/classinfo.frm‘ innobackupex: Copying ‘/tmp/full-backup/2015-06-25_06-02-41/management/admin.frm‘ to ‘/tmp/full-backup/2015-06-25_05-58-26/management/admin.frm‘ 150625 06:07:10 innobackupex: completed OK! ←#258#[email protected] ~ →rm -rf /mydata/data1/* #删除数据文件目录 ←#259#[email protected] ~ →innobackupex --copy-back /tmp/full-backup/2015-06-25_05-58-26/ #恢复 。。。。。。。。。。。。。。。。 innobackupex: Starting to copy InnoDB log files innobackupex: in ‘/tmp/full-backup/2015-06-25_05-58-26‘ innobackupex: back to original InnoDB log directory ‘/mydata/data1‘ innobackupex: Finished copying back files. 150625 06:12:29 innobackupex: completed OK! ←#276#[email protected] /mydata/data1 →chown -R mysql.mysql ./* #修改属主和属组
本文出自 “小华的博客” 博客，请务必保留此出处http://coderhsf.blog.51cto.com/12629645/1922281
以上是关于用XtraBackup备份时报错又一个错误，这是啥原因的主要内容，如果未能解决你的问题，请参考以下文章
MySQL Backup--Xtrabackup备份常见错误