Percona XtraBackup是基于MySQL的服务器的开源热备份实用程序,在备份期间不会锁定您的数据库。它可以备份MySQL 5.1、5.5、5.6 和 5.7 服务器上的InnoDB、XtraDB 和MyISAM表中的数据,以及带有 XtraDB 的 Percona Server。
笔记
Percona XtraBackup 2.1中删除了对 InnoDB 5.1 内置的支持
有关其许多高级功能的高级概述,包括功能比较,请参阅关于 Percona XtraBackup。
无论是 24x7 高负载服务器还是低事务量环境,Percona XtraBackup旨在使备份成为一个无缝过程,而不会破坏生产环境中服务器的性能。提供商业支持合同。
重要的
Percona XtraBackup 2.4 不支持备份在MySQL 8.0、Percona Server for MySQL 8.0或Percona XtraDB Cluster 8.0中创建的数据库。
使用Percona XtraBackup 8.0 <https://www.percona.com/downloads/Percona-XtraBackup-LATEST/#>__ 备份MySQL 8.0、Percona Server for MySQL 8.0和Percona XtraDB Cluster 8.0中的数据库。
介绍
安装
- 在Debian和Ubuntu上安装Percona XtraBackup
- 在 Red Hat Enterprise Linux 和 CentOS 上安装Percona XtraBackup
- 从二进制压缩包安装Percona XtraBackup
- 从源代码编译和安装
在 Docker 中运行
先决条件
备份方案
用户说明书
高级功能
教程、食谱、操作方法
参考
- Percona XtraBackup 2.4 发行说明
- xtrabackup 选项参考
- innobackupex 选项参考
- xbcloud 二进制文件
- 指数退避
- 将 xbcloud 二进制文件与 Microsoft Azure 云存储一起使用
- xbcrypt 二进制文件
- xbstream 二进制文件
- 已知问题和限制
- 经常问的问题
- 词汇表
- Percona XtraBackup 创建的文件索引
- 商标政策
- 版本检查
关于 Percona XtraBackup
Percona XtraBackup是世界上唯一一款开源、免费的MySQL热备份软件,可为InnoDB和 XtraDB 数据库执行非阻塞备份。使用Percona XtraBackup,您可以获得以下好处:
- 快速可靠地完成备份
- 备份期间不间断的事务处理
- 节省磁盘空间和网络带宽
- 自动备份验证
- 恢复时间更快,正常运行时间更长
请参阅Percona 软件和平台生命周期中的兼容性矩阵
了解 Percona XtraBackup 支持哪些版本的 MySQL、MariaDB 和 Percona Server for MySQL 并支持使用任何类型的备份进行加密。
支持 InnoDB、Percona XtraDB Cluster 和HailDB存储引擎的非阻塞备份。此外,Percona XtraBackup 可以通过在备份结束时短暂暂停写入来备份以下存储引擎:MyISAM、Merge <.MRG>
和Archive <.ARM>
,包括分区表、触发器和数据库选项。InnoDB 表在复制非 InnoDB 数据时仍处于锁定状态。启用 Percona XtraDB Cluster 更改页面跟踪的 Percona Server 支持快速增量备份。
重要的
Percona XtraBackup 2.4 仅支持 Percona XtraDB Cluster 5.7。Percona XtraBackup 2.4 不支持 MyRocks 存储引擎或 TokuDB 存储引擎。Percona XtraBackup与 MariaDB 10.3 及更高版本不兼容。
Percona 的企业级商业MySQL 支持合同包括对 Percona XtraBackup的支持。我们建议支持关键生产部署。
Percona XtraBackup 有哪些特点?
这是Percona XtraBackup功能的简短列表。有关更多信息,请参阅文档。
- 在不暂停数据库的情况下创建热 InnoDB 备份
- 对 MySQL 进行增量备份
- 将压缩的 MySQL 备份流式传输到另一台服务器
- 在线在 MySQL 服务器之间移动表
- 轻松创建新的 MySQL 复制副本
- 在不增加服务器负载的情况下备份 MySQL
- 备份锁是
FLUSH TABLES WITH READ LOCK
Percona Server 5.6+ 中可用的轻量级替代方案。Percona XtraBackup 自动使用它们来复制非 InnoDB 数据,以避免阻塞修改 InnoDB 表的 DML 查询。 - Percona XtraBackup 根据每秒 IO 操作数执行节流。
- Percona XtraBackup 会跳过二级索引页并在准备好紧凑备份时重新创建它们。
- Percona XtraBackup 甚至可以从完整备份中导出单个表,无论 InnoDB 版本如何。
- 使用 Percona XtraBackup 导出的表可以导入 Percona Server 5.1、5.5 或 5.6+,或 MySQL 5.6+。
Percona XtraBackup 的工作原理
Percona XtraBackup基于 InnoDB 的崩溃恢复功能。它会复制您的InnoDB数据文件,从而导致数据内部不一致;但随后它会对文件执行崩溃恢复,以使它们再次成为一致的、可用的数据库。
这是因为InnoDB维护了一个重做日志,也称为事务日志。这包含对 InnoDB 数据的每次更改的记录。当InnoDB启动时,它会检查数据文件和事务日志,并执行两个步骤。它将提交的事务日志条目应用于数据文件,并对任何修改数据但未提交的事务执行撤消操作。
Percona XtraBackup的工作原理是在启动时记住日志序列号 (LSN),然后复制数据文件。这样做需要一些时间,因此如果文件正在更改,那么它们会反映数据库在不同时间点的状态。同时,Percona XtraBackup运行一个后台进程来监视事务日志文件,并从中复制更改。Percona XtraBackup需要不断地执行此操作,因为事务日志是以循环方式编写的,并且可以重复使用。Percona XtraBackup自开始执行以来对数据文件的每次更改都需要事务日志记录。
Percona XtraBackup将使用备份锁 作为FLUSH TABLES WITH READ LOCK
. 此功能在Percona Server for MySQL 5.6+ 中可用。Percona XtraBackup 自动使用它来复制非 InnoDB 数据,以避免阻塞修改InnoDB表的 DML 查询。当服务器支持备份锁时,xtrabackup将首先复制InnoDB数据,运行LOCK TABLES FOR BACKUP
并复制MyISAM表和.frm
文件。完成此操作后,将开始备份文件。它将备份.frm
, .MRG
, .MYD
, .MYI
, .TRG
, .TRN
, .ARM
, .ARZ
, .CSM
, .CSV
,.par
, 和.opt
文件。
笔记
锁定仅对MyISAM和其他非 InnoDB 表进行,并且仅在 Percona XtraBackup完成备份所有 InnoDB/XtraDB 数据和日志之后进行。Percona XtraBackup将使用备份锁作为FLUSH TABLES WITH READ LOCK
. 此功能在Percona Server for MySQL 5.6+ 中可用。Percona XtraBackup 自动使用它来复制非 InnoDB 数据,以避免阻塞修改InnoDB表的 DML 查询。
之后,xtrabackup将用于LOCK BINLOG FOR BACKUP
阻止所有可能更改二进制日志位置或 Exec_Master_Log_Pos
(Exec_Gtid_Set
即与复制副本上的当前 SQL 线程状态相对应的源二进制日志坐标)的操作,如SHOW MASTER/SLAVE STATUS
. xtrabackup然后将完成复制 REDO 日志文件并获取二进制日志坐标。完成后,xtrabackup将解锁二进制日志和表。
最后,二进制日志位置将被打印到STDERR
xtrabackup退出,如果一切正常则返回 0。
请注意,STDERR
xtrabackup没有写入任何文件中。您必须将其重定向到一个文件,例如xtrabackup OPTIONS 2> backupout.log
.
它还将在备份目录中创建以下文件。
在准备阶段,Percona XtraBackup使用复制的事务日志文件对复制的数据文件执行崩溃恢复。完成此操作后,数据库即可恢复和使用。
备份的MyISAM和InnoDB表最终会相互一致,因为在准备(恢复)过程之后,InnoDB的数据会前滚到备份完成的点,而不是回滚到备份完成的点开始了。该时间点与FLUSH TABLES WITH READ LOCK
获取的位置相匹配,因此MyISAM数据和准备好的InnoDB数据是同步的。
xtrabackup和innobackupex工具都提供了许多前面的解释中没有提到的特性。手册中更详细地解释了每个工具的功能。简而言之,这些工具允许您使用复制数据文件、复制日志文件和将日志应用到数据的各种组合来执行流式备份和增量备份等操作。
恢复备份
要使用xtrabackup恢复备份,您可以使用 xtrabackup --copy-back
或xtrabackup --move-back
选项。
xtrabackup将从my.cnf
变量datadir
, innodb_data_home_dir
,中读取innodb_data_file_path
, innodb_log_group_home_dir
并检查目录是否存在。
它将首先复制MyISAM表、索引等(.frm
、.MRG
、 .MYD
、.MYI
、.TRG
、.TRN
、.ARM
、 .ARZ
、.CSM
、和 .opt 文件),然后.CSV
是InnoDB表和索引,最后是日志文件。它会在复制文件时保留文件的属性,您可能必须在启动数据库服务器之前将文件的所有权更改为,因为它们将归创建备份的用户所有。parmysql
或者,该xtrabackup --move-back
选项可用于恢复备份。此选项类似于xtrabackup --copy-back
唯一的区别,而不是复制文件,而是将它们移动到目标位置。由于此选项会删除备份文件,因此请谨慎使用。当没有足够的可用磁盘空间来保存数据文件及其备份副本时,它很有用。
在 Debian 和 Ubuntu 上安装 Percona XtraBackup
Percona XtraBackup软件存储库和Percona 下载页面提供了即用型软件包。
Percona 软件和平台生命周期中描述了有关支持的平台、产品和版本的特定信息。
每个 DEB 包中都有什么?
该percona-xtrabackup-24
软件包包含最新的Percona XtraBackup GA 二进制文件和相关文件。
percona-xtrabackup-dbg-24
包中包含二进制文件的调试符号percona-xtrabackup-24
。
该percona-xtrabackup-test-24
软件包包含 Percona XtraBackup的测试套件。
该percona-xtrabackup
软件包包含旧版本的 Percona XtraBackup。
通过percona-release安装Percona XtraBackup
Percona XtraBackup与许多其他Percona产品一样,是使用percona-release包配置工具安装的。
- 从 Percona web下载一个用于percona-release存储库包的 deb 包:
- 使用
dpkg
. 为此,请以 root 身份或 with 运行以下命令sudo
:
2.
$ wget https://repo.percona.com/apt/percona-release_latest.
$(lsb_release -sc
)_all.deb
4.
$ sudo dpkg -i percona-release_latest.
$(lsb_release -sc
)_all.deb
安装此软件包后,应添加 Percona 存储库。您可以在 /etc/apt/sources.list.d/percona-release.list 文件中检查存储库设置。
- 启用存储库:
percona-release enable-only tools release
如果Percona XtraBackup打算与上游 MySQL 服务器结合使用,您只需启用tools
存储库:percona-release enable-only tools
.
- 之后,您可以安装
percona-xtrabackup-24
软件包: - 为了进行压缩备份,请安装
qpress
软件包:
7.
$ sudo apt install percona-xtrabackup-24
9.
$ sudo apt install qpress
Apt-Pinning 软件包
在某些情况下,您可能需要“固定”选定的包以避免从分发存储库升级。您需要创建一个新文件 /etc/apt/preferences.d/00percona.pref
并在其中添加以下行:
Package: *
Pin: release o=Percona Development Team
Pin-Priority: 1001
有关固定的更多信息,您可以查看官方 debian wiki。
使用下载的 deb 包安装Percona XtraBackup
从下载页面为您的架构下载所需系列的软件包 。以下示例为Debian 9.0下载Percona XtraBackup 2.4.20 发行包:
$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.20/
\
binary/debian/stretch/x86_64/percona-xtrabackup-24_2.4.20-1.stretch_amd64.deb
现在您可以通过运行以下命令安装Percona XtraBackup:
$ sudo dpkg -i percona-xtrabackup-24_2.4.20-1.stretch_amd64.deb
笔记
像这样手动安装软件包,您必须解决所有依赖项并自己安装缺少的软件包。
更新 Debian 10 中的 Curl 实用程序
Debian 10 中的默认 curl 版本 7.64.0 在尝试重用已关闭的连接时存在已知问题。此问题直接影响xbcloud
并且用户可能会看到间歇性备份失败。
有关更多详细信息,请参阅curl #3750或curl #3763。
按照以下步骤将 curl 升级到版本 7.74.0:
- 编辑
/etc/apt/sources.list
以添加以下内容: - 刷新
apt
来源: - 从以下位置安装版本
buster-backports
: - 验证版本号:
2.
deb http://ftp.de.debian.org/debian buster-backports main
4.
sudo apt update
6.
$ sudo apt install curl/buster-backports
8.
$ curl --version
9.
curl
7.74.0
(x86_64-pc-linux-gnu
)libcurl/7.74.0
卸载Percona XtraBackup
要卸载Percona XtraBackup,您需要删除所有已安装的软件包。
- 移除包裹
2.
$ sudo apt remove percona-xtrabackup-24
在 Red Hat Enterprise Linux 和 CentOS 上安装 Percona XtraBackup
Percona XtraBackup软件存储库和下载页面提供了即用型软件包。Percona yum
存储库支持流行的基于RPM的操作系统,包括Amazon Linux AMI。
安装Percona Yum存储库的最简单方法是安装一个RPM 来配置yum
和安装Percona GPG 密钥。
Percona 软件和平台生命周期中描述了有关支持的平台、产品和版本的特定信息。
每个 RPM 包中有什么?
该percona-xtrabackup-24
软件包包含最新的Percona XtraBackup GA 二进制文件和相关文件。
percona-xtrabackup-24-debuginfo
包中包含二进制文件的调试符号percona-xtrabackup-24
。
该percona-xtrabackup-test-24
软件包包含Percona XtraBackup的测试套件。
该percona-xtrabackup
软件包包含旧版本的 Percona XtraBackup。
从 Percona存储库安装Percona XtraBackupyum
- 安装
percona-release
配置工具
root
您可以通过以用户身份或使用 以下命令运行以下命令来安装 percona-release 的 yum 存储库sudo
:
$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
您应该会看到一些输出,如下所示:
Retrieving https://repo.percona.com/yum/percona-release-latest.noarch.rpm
Preparing...
########################################### [100%]
1
:percona-release
########################################### [100%]
笔记
RHEL / Centos 5 不支持直接从远程位置安装软件包,因此您需要先下载软件包并使用 rpm 手动安装:
$ wget https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ rpm -ivH percona-release-latest.noarch.rpm
- 测试存储库
通过执行以下命令,确保现在可以从存储库中获得包:
yum list
|grep percona
您应该会看到类似于以下内容的输出:
...
percona-xtrabackup-20.x86_64
2.0.8-587.rhel5 percona-release-x86_64
percona-xtrabackup-20-debuginfo.x86_64
2.0.8-587.rhel5 percona-release-x86_64
percona-xtrabackup-20-test.x86_64
2.0.8-587.rhel5 percona-release-x86_64
percona-xtrabackup-21.x86_64
2.1.9-746.rhel5 percona-release-x86_64
percona-xtrabackup-21-debuginfo.x86_64
2.1.9-746.rhel5 percona-release-x86_64
percona-xtrabackup-22.x86_64
2.2.13-1.el5 percona-release-x86_64
percona-xtrabackup-22-debuginfo.x86_64
2.2.13-1.el5 percona-release-x86_64
percona-xtrabackup-debuginfo.x86_64
2.3.5-1.el5 percona-release-x86_64
percona-xtrabackup-test.x86_64
2.3.5-1.el5 percona-release-x86_64
percona-xtrabackup-test-21.x86_64
2.1.9-746.rhel5 percona-release-x86_64
percona-xtrabackup-test-22.x86_64
2.2.13-1.el5 percona-release-x86_64
...
- 启用存储库:
percona-release enable-only tools release
如果Percona XtraBackup 打算与上游 MySQL 服务器结合使用,您只需要启用tools
存储库:percona-release enable-only tools
.
- 通过运行安装Percona XtraBackup:
yum install percona-xtrabackup-24
警告
为了在版本 7 之前的 CentOS 上成功安装Percona XtraBackuplibev
,需要先安装该软件包。libev
可以从EPEL存储库安装此软件包。
Perconayum
测试库
Percona 提供来自我们测试存储库的预发布版本。要订阅测试存储库,您需要在 /etc/yum.repos.d/percona-release.repo 中启用测试存储库。为此,请同时设置 和 percona-testing-$basearch
(请注意,此文件中有 3 个部分:发布、测试和实验 - 在这种情况下,需要更新的是第二个部分)。注意:如果尚未安装,您需要先安装 Percona 存储库(参考上文)。percona-testing-noarchenabled = 1
- 为了能够进行压缩备份,请安装
qpress
软件包:
2.
$ yum install qpress
也可以看看
使用下载的 rpm 包安装Percona XtraBackup
从下载页面为您的架构下载所需系列的软件包 。以下示例将为CentOS 7下载Percona XtraBackup 2.4.4 发行包 :
$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/
\
binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
现在您可以通过运行以下命令安装Percona XtraBackup:
$ yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
笔记
像这样手动安装包时,您需要确保解决所有依赖项并自己安装缺少的包。
卸载Percona XtraBackup
要完全卸载Percona XtraBackup,您需要删除所有已安装的软件包。
移除包裹
yum remove percona-xtrabackup
从二进制压缩包安装 Percona XtraBackup
Percona提供Percona XtraBackup的二进制压缩包。二进制 tarball 包含预编译的可执行文件、库和其他依赖项,并且是压缩tar
档案。将二进制 tarball 解压缩到任何路径。
二进制 tarball 可供下载和安装。下表列出了Linux - Generic
. 为您的安装选择Percona XtraBackup 2.4 版本号和 tarball 类型。二进制 tarball 支持所有发行版。
下载二进制 tarball 后,将 tarball 解压缩到您选择的文件位置。
类型 |
姓名 |
描述 |
满的 |
percona-xtrabackup–Linux.x86_64.glibc2.12.tar.gz |
包含二进制文件、库、测试文件和调试符号 |
最小 |
percona-xtrabackup–Linux.x86_64.glibc2.12-minimal.tar.gz |
包含二进制文件和库,但不包含测试文件或调试符号 |
获取并提取正确的二进制 tarball。例如,以下下载 2.4.24 版的完整 tarball:
$ wget https://downloads.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.24/binary/tarball/percona-xtrabackup-2.4.24-Linux-x86_64.glibc2.12.tar.gz
--2022-04-13
14:34:45-- https://downloads.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.24/binary/tarball/percona-xtrabackup-2.4.24-Linux-x86_64.glibc2.12.tar.gz
Resolving downloads.percona.com
(downloads.percona.com
)...
162.220.4.221,
162.220.4.222,
74.121.199.231
Connecting to downloads.percona.com
(downloads.percona.com
)|162.220.4.221
|:443... connected.
HTTP request sent, awaiting response...
200OK
Length:
76263220(
73M
)[
application/x-gzip
]
Saving to: ‘percona-xtrabackup-2.4.24-Linux-x86_64.glibc2.12.tar.gz’
percona-xtrabackup-2.4.24-Linux-x86_64
100%
[==========================================================================>
]72
.73M
5.29MB/s
in20s
2022
-04-13
14:35:05
(3.61 MB/s
)- ‘percona-xtrabackup-2.4.24-Linux-x86_64.glibc2.12.tar.gz’ saved
[76263220/76263220
]
$ tar xvf percona-xtrabackup-2.4.21-Linux-x86_64.glibc2.12.tar.gz
从二进制 tarball 安装需要手动执行某些任务,例如配置设置和策略,存储库包安装会自动执行这些任务。
从源代码编译和安装
源代码可从Percona XtraBackup Github 项目获得。获取代码的最简单方法是使用git clone
命令。然后,切换到您要安装的发布分支,例如2.4。
$ git clone https://github.com/percona/percona-xtrabackup.git
$
cdpercona-xtrabackup
$ git checkout
2.4
第 1 步:安装先决条件
必须安装以下软件包和工具才能从源代码编译Percona XtraBackup。这些可能因系统而异。
重要的
为了从源代码构建Percona XtraBackup v8.0,您需要使用cmake
版本 3。在您的发行版中,它可以作为单独的包cmake3
或cmake
. 要检查安装了哪个版本,请运行cmake --version
,如果确实报告版本 3,请cmake3
为您的系统安装。
也可以看看
https://cmake.org/
Debian 或 Ubuntu 使用apt
$ sudo apt install build-essential flex bison automake autoconf
\
libtool cmake libaio-dev mysql-client libncurses-dev zlib1g-dev
\
libgcrypt11-dev libev-dev libcurl4-gnutls-dev vim-common
要安装手册页,请安装python3-sphinx
软件包:
$ sudo apt install python3-sphinx
CentOS 或 Red Hat 使用yum
Percona Xtrabackup 需要 GCC 5.3 或更高版本。如果您的系统上安装的 GCC 版本较低,那么您可能需要安装并启用基于 发行版的 Developer ToolsetRPM
,以确保您使用最新的 GCC 编译器和开发工具。然后,安装cmake
和其他依赖项:
$ sudo yum install cmake openssl-devel libaio libaio-devel automake autoconf
\
bison libtool ncurses-devel libgcrypt-devel libev-devel libcurl-devel zlib-devel
\
vim-common
要安装手册页,请安装python3-sphinx
软件包:
$ sudo yum install python3-sphinx
第 2 步:生成构建管道
在这一步,您已经cmake
运行了CMakeList.txt
文件中的命令来生成构建管道,即将用于编译源代码的本地构建环境)。
- 切换到克隆 Percona XtraBackup 存储库的目录
- 创建一个目录来存储编译后的文件,然后切换到该目录:
- 运行
cmake
或cmake3
。无论哪种情况,您需要使用的选项都是相同的。
2.
$
cdpercona-xtrabackup
4.
$ mkdir build
5.
$
cdbuild
笔记
您可以使用手册页构建Percona XtraBackup,但这需要python-sphinx
在每个发行版的主存储库中都没有可用的包。如果您安装了该python-sphinx
软件包,则需要-DWITH_MAN_PAGES=OFF
从先前的命令中删除该软件包。
$ cmake -DWITH_BOOST
=PATH-TO-BOOST-LIBRARY -DDOWNLOAD_BOOST
=ON
\
-DBUILD_CONFIG
=xtrabackup_release -DWITH_MAN_PAGES
=OFF -B ..
有关参数的更多信息
-DWITH_BOOST
对于-DWITH_BOOST
参数,指定将 boost 库下载到的目录的名称。该目录将在您的当前目录中自动创建。
-B (--build)
Percona XtraBackup配置为禁止make
在存储源的同一目录中生成构建管道。该-B
参数是指包含源代码的目录。在此示例中,我们使用父目录的相对路径 (..)。
重要的
CMakeLists.txt:367 (MESSAGE) 处的 CMake 错误:请不要在源代码中构建。强烈建议使用外源构建:您可以为同一个源构建多个构建,并且有一种简单的清理方法,只需删除构建目录(请注意,'make clean' 或 'make distclean'不起作用)
您可以通过使用 -DFORCE_INSOURCE_BUILD=1 调用 cmake 来强制进行源内构建
-DWITH_MAN_PAGES
要构建Percona XtraBackup手册页,ON
请在命令行中使用或删除此参数(ON
默认情况下)。
要安装手册页,请安装python3-sphinx
软件包:
第二步:编译源代码
要在构建目录中编译源代码,请使用make
命令。
重要的
您打算编译Percona XtraBackup 8.0 的计算机必须至少有 2G 的可用 RAM。
- 切换到
build
目录(在第 2 步创建:生成构建管道)。 - 运行
make
命令。此命令可能需要很长时间才能完成。
3.
$ make
第 3 步:在目标系统上安装
以下命令将所有Percona XtraBackup二进制文件xtrabackup 和测试安装到目标系统上的默认位置:/usr/local/xtrabackup
.
运行make install
以将Percona XtraBackup安装到默认位置。
$ sudo make install
安装到非默认位置
您可以使用DESTDIR
参数 withmake install
将Percona XtraBackup安装到另一个位置。确保有效用户能够写入您选择的目的地。
$ sudo make
DESTDIR=<DIR_NAME> install
实际上,目标目录由适用的安装布局 ( -DINSTALL_LAYOUT
) 确定cmake
(请参阅步骤 2:生成构建管道)。除了安装目录之外,此参数还控制您可以为您的系统调整的许多其他目标。
默认情况下,该参数设置为STANDALONE
,表示安装目录为 /usr/local/xtrabackup。
也可以看看
第 4 步:运行
在您的系统上安装Percona XtraBackup后,您可以使用以下xtrabackup
命令的完整路径运行它:
$ /usr/local/xtrabackup/bin/xtrabackup
如果您想直接在命令行上使用该命令,请更新您的 PATH 环境变量。
$#Setting
$PATHon the
commandline
$
PATH=$PATH:/usr/local/xtrabackup/bin/xtrabackup
$#Run xtrabackup directly
$ xtrabackup
或者,您可以考虑放置一个软链接(使用)到您的环境变量ln -s
中列出的位置之一。PATH
也可以看看
man ln
要使用 来查看文档man
,请更新MANPATH
变量。
在 Docker 容器中运行 Percona XtraBackup
Docker 允许您在称为容器的轻量级单元中运行应用程序。
您可以在 Docker 容器中运行Percona XtraBackup,而无需安装产品。容器中提供了所有必需的库。作为一个轻量级的执行环境,Docker 容器支持创建每个程序在单独的容器中运行的配置。您可以在一个容器中运行 Percona Server for MySQL,而在另一个容器中运行Percona XtraBackup。Docker 镜像提供了一系列选项。
基于 Docker 镜像创建 Docker 容器。Percona XtraBackup 的 Docker 映像在 Docker Hub 上公开托管percona/percona-xtrabackup
。
$ sudo docker create ... percona/percona-xtrabackup --name xtrabackup ...
本节范围
本节演示如何在另一个 Docker 容器中运行的 Percona Server for MySQL 上备份数据。
安装 Docker
您的操作系统可能已经为docker提供了一个包。但是,您的操作系统提供的 Docker 版本可能已经过时。
使用 Docker 站点提供的适用于您的操作系统的安装说明来设置最新版本的docker。
笔记
Docker 文档:*如何使用 Docker *安装 *入门
连接到 Percona Server for MySQL 容器
Percona XtraBackup 与数据库服务器结合使用。在为 Percona XtraBackup 运行 Docker 容器时,您可以为安装在主机上或在单独的 Docker 容器中运行的数据库服务器进行备份。
要在主机或 Docker 容器中设置数据库服务器,请遵循您打算与 Percona XtraBackup 一起使用的受支持产品的文档。
也可以看看
Percona Server for MySQL 文档: *在主机上安装 *在 Docker 容器中运行
$ sudo docker run -d --name percona-server-mysql-5.7
\
-e
MYSQL_ROOT_PASSWORD=root percona/percona-server:5.7
Percona Server for MySQL 运行后,立即向其中添加一些数据。现在,您可以使用 Percona XtraBackup 进行备份了。
从 Percona XtraBackup 镜像创建 Docker 容器
您可以使用 docker create或docker run命令基于 Percona XtraBackup 映像创建 Docker 容器。docker create 创建一个 Docker 容器并使其可供以后启动。
Docker 从 Docker Hub 下载 Percona XtraBackup 映像。如果不是第一次使用所选镜像,Docker 会使用本地可用的镜像。
$ sudo docker create --name percona-xtrabackup-2.4 --volumes-from percona-server-mysql-5.7
\
percona/percona-xtrabackup:2.4
\
xtrabackup --backup --datadir
=/var/lib/mysql/ --target-dir
=/backup
\
--user
=root --password
=mysql
--name
为您的新 Docker 容器起一个有意义的名称,以便您可以轻松地在其他容器中找到它。
--volumes-from
引用percona -server-mysql表示您打算使用与percona-server-mysql容器相同的数据。
使用与创建容器时完全相同的参数运行容器:
$ sudo docker start -ai percona-xtrabackup-2.4
此命令启动percona-xtrabackup容器,附加到其输入/输出流,并打开一个交互式 shell。
docker run是一个快捷命令,它创建一个 Docker 容器,然后立即运行它。
$ sudo docker run --name percona-xtrabackup-2.4 --volumes-from percona-server-mysql-5.7
\
percona/percona-xtrabackup:2.4
xtrabackup --backup --data-dir
=/var/lib/mysql --target-dir
=/backup --user
=root --password
=mysql
也可以看看
Docker 文档中的更多内容 * Docker 卷作为容器的持久数据存储 *有关容器的更多信息
所需的连接和权限
Percona XtraBackup需要能够连接到数据库服务器并在创建备份时、在某些情况下准备时以及在恢复时对服务器和 datadir 执行操作。为此,必须满足其执行的特权和权限要求。
权限是指允许系统用户在数据库服务器中进行的操作。它们是在数据库服务器上设置的,仅适用于数据库服务器中的用户。
权限是允许用户在系统上执行操作的权限,例如在某个目录上读取、写入或执行或启动/停止系统服务。它们是在系统级别设置的,仅适用于系统用户。
无论使用xtrabackup还是 innobackupex,都涉及到两个参与者:调用程序的用户 - 系统用户- 以及在数据库服务器中执行操作的用户 -数据库用户。请注意,这些是不同位置的不同用户,即使他们可能具有相同的用户名。
本文档中对 innobackupex 和xtrabackup的所有调用都假定系统用户具有适当的权限,并且您正在提供连接数据库服务器的相关选项 - 除了要执行的操作的选项 - 并且数据库用户具有足够的权限。
连接到服务器
用于连接服务器的数据库用户及其密码由xtrabackup --user
andxtrabackup –password
选项指定:
$ xtrabackup --user
=DVADER --password
=14MY0URF4TH3R --backup
\
--target-dir
=/data/bkps/
$ innobackupex --user
=DBUSER --password
=SECRET /path/to/backup/dir/
$ innobackupex --user
=LUKE --password
=US3TH3F0RC3 --stream
=tar ./
|bzip2 -
如果您不使用该xtrabackup --user
选项,Percona XtraBackup 将假定数据库用户的名称是执行它的系统用户。
其他连接选项
根据您的系统,您可能需要指定以下一个或多个选项来连接到服务器:
选项 |
描述 |
-港口 |
使用 TCP/IP 连接到数据库服务器时使用的端口。 |
-插座 |
连接到本地数据库时使用的套接字。 |
-主持人 |
使用 TCP/IP 连接到数据库服务器时使用的主机。 |
这些选项被传递给 mysql 子进程而不做任何更改,请参阅mysql --help
详细信息。
笔记
在多个服务器实例的情况下,必须指定正确的连接参数(端口、套接字、主机),以便xtrabackup与正确的服务器通信。
所需的权限和特权
一旦连接到服务器,为了执行备份,您将需要 服务器数据目录中文件系统级别READ
的EXECUTE
权限。
数据库用户需要对要备份的表/数据库具有以下权限:
RELOAD
和LOCK TABLES
(除非 –no-lock选项已指定)以便在开始复制文件之前FLUSH TABLES WITH READ LOCK
和FLUSH ENGINE LOGS
开始复制文件,并且LOCK TABLES FOR BACKUP
在使用备份锁LOCK BINLOG FOR BACKUP
时需要此权限。REPLICATION CLIENT
为了获得二进制日志位置。CREATE TABLESPACE
为了导入表(请参阅恢复单个表)。PROCESS
为了运行SHOW ENGINE INNODB STATUS
(这是强制性的),并且可以选择查看在服务器上运行的所有线程(请参阅改进的 FLUSH TABLES WITH READ LOCK 处理)。SUPER
为了在复制环境中启动/停止副本线程,请使用XtraDB Changed Page Tracking for Incremental Backups和改进 FLUSH TABLES WITH READ LOCK 处理。CREATE
权限以创建 PERCONA_SCHEMA.xtrabackup_history数据库和表。ALTER
权限以升级 PERCONA_SCHEMA.xtrabackup_history数据库和表。INSERT
权限,以便将历史记录添加到 PERCONA_SCHEMA.xtrabackup_history表。SELECT
特权,以便使用innobackupex --incremental-history-name
或innobackupex --incremental-history-uuid
为了让功能在PERCONA_SCHEMA.xtrabackup_history表中查找innodb_to_lsn
值 。
可以在 Percona XtraBackup 的工作原理中找到有关何时使用这些的说明。
创建具有完整备份所需的最低权限的数据库用户的 SQL 示例如下:
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cret';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO
'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;
配置 xtrabackup
所有xtrabackup配置都是通过选项完成的,其行为与标准MySQL程序选项完全一样:它们可以在命令行中指定,也可以通过/etc/my.cnf
.
xtrabackup二进制文件按顺序从任何配置文件中读取和[mysqld]
部分。[xtrabackup]
这样它就可以从您现有的MySQL安装中读取其选项,例如 datadir 或一些InnoDB选项。如果要覆盖这些,只需在[xtrabackup]
部分中指定它们,因为稍后阅读,它将优先。
如果您不想,则无需在其中添加任何配置my.cnf
。您可以简单地在命令行上指定选项。通常,您可能会觉得方便放置在文件[xtrabackup]
部分中的唯一内容是选择默认放置备份的目录,例如:my.cnftarget_dir
[xtrabackup]
target_dir = /data/backups/mysql/
本手册将假定您没有任何基于文件的 xtrabackup配置,因此它将始终显示显式使用的命令行选项。有关所有配置选项的详细信息,请参阅选项和变量参考。
xtrabackup二进制文件不接受 与服务器二进制my.cnf
文件完全相同的语法。mysqld
由于历史原因,mysqld
服务器二进制文件接受带有 xtrabackup不理解的--set-variable=<variable>=<value>
语法的参数。如果你的 my.cnf 文件有这样的配置指令,你应该用语法重写它们。--variable=value
系统配置和 NFS 卷
xtrabackup工具在大多数系统上不需要特殊配置。但是,调用xtrabackup --target-dir
时 所在的存储必须正常运行fsync()
。特别是,我们注意到未使用该sync
选项安装的 NFS 卷可能不会真正同步数据。因此,如果您备份到使用异步选项挂载的 NFS 卷,然后尝试从也挂载该卷的其他服务器准备备份,则数据可能看起来已损坏。您可以使用 sync
mount 选项来避免这个问题。
备份周期 - 完整备份
创建备份
要创建备份,xtrabackup
请使用xtrabackup --backup option
. 您还需要指定一个xtrabackup --target-dir
选项,即存储备份的位置,如果InnoDB数据或日志文件未存储在同一目录中,您可能还需要指定它们的位置。如果目标目录不存在,xtrabackup 会创建它。如果该目录确实存在并且为空,则 xtrabackup 将成功。xtrabackup 不会覆盖现有文件,它将因操作系统错误 17 失败,file exists
.
要启动备份过程,请运行:
$ xtrabackup --backup --target-dir
=/data/backups/
这会将备份存储在/data/backups/
. 如果指定相对路径,则目标目录将相对于当前目录。
在备份过程中,您应该看到很多输出显示正在复制的数据文件,以及日志文件线程重复扫描日志文件并从中复制。这是一个示例,显示了日志线程在后台扫描日志,以及一个文件复制线程在 ibdata1 文件上工作:
160906 10:19:17 Finished backing up non-InnoDB tables and files
160906 10:19:17 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '62988944'
xtrabackup: Stopping log copying thread.
.160906 10:19:18 >> log scanned up to (137343534)
160906 10:19:18 Executing UNLOCK TABLES
160906 10:19:18 All tables unlocked
160906 10:19:18 Backup created in directory '/data/backups/'
160906 10:19:18 [00] Writing backup-my.cnf
160906 10:19:18 [00] ...done
160906 10:19:18 [00] Writing xtrabackup_info
160906 10:19:18 [00] ...done
xtrabackup: Transaction log of lsn (26970807) to (137343534) was copied.
160906 10:19:18 completed OK!
您应该看到的最后一件事类似于以下内容,其中的值<LSN>
将是一个取决于您的系统的数字:
xtrabackup: Transaction log of lsn (<SLN>) to (<LSN>) was copied.
笔记
日志复制线程每秒检查一次事务日志以查看是否有任何新的日志记录需要被复制,但是日志复制线程可能无法跟上去往的写入量事务日志,并且当日志记录在被读取之前被覆盖时会发生错误。
备份完成后,目标目录将包含如下文件,假设您有一个 InnoDB 表test.tbl1
并且您使用的是 MySQL 的innodb_file_per_table
选项:
$ ls -lh /data/backups/
total 182M
drwx------
7root root
4.0K Sep
610
:19 .
drwxrwxrwt
11root root
4.0K Sep
611
:05 ..
-rw-r-----
1root root
387Sep
610
:19 backup-my.cnf
-rw-r-----
1root root 76M Sep
610
:19 ibdata1
drwx------
2root root
4.0K Sep
610
:19 mysql
drwx------
2root root
4.0K Sep
610
:19 performance_schema
drwx------
2root root
4.0K Sep
610
:19 sbtest
drwx------
2root root
4.0K Sep
610
:19
test
drwx------
2root root
4.0K Sep
610
:19 world2
-rw-r-----
1root root
116Sep
610
:19 xtrabackup_checkpoints
-rw-r-----
1root root
433Sep
610
:19 xtrabackup_info
-rw-r-----
1root root 106M Sep
610
:19 xtrabackup_logfile
备份可能需要很长时间,具体取决于数据库的大小。随时取消都是安全的,因为它不会修改数据库。
下一步是让您的备份准备好恢复。
准备备份
使用该选项进行备份后xtrabackup --backup
,您首先需要准备它以恢复它。数据文件在准备好之前不是时间点一致的,因为它们在程序运行时在不同时间被复制,并且在发生这种情况时它们可能已经被更改。如果您尝试使用这些数据文件启动 InnoDB,它将检测损坏并自行崩溃以防止您在损坏的数据上运行。该xtrabackup --prepare
步骤使文件在单个时刻完全一致,因此您可以在它们上运行InnoDB。
您可以在任何机器上运行准备操作;它不需要位于原始服务器或您要还原到的服务器上。您可以将备份复制到实用程序服务器并在那里进行准备。
笔记
您可以使用较新的Percona XtraBackup版本来准备使用旧版本创建的备份,反之则不行。应使用支持该服务器版本的最新Percona XtraBackup版本在不受支持的服务器版本上准备备份。例如,如果有一个使用Percona XtraBackup 1.6 创建的 MySQL 5.0 备份,则不支持使用Percona XtraBackup 2.3 准备备份,因为在Percona XtraBackup 2.1 中删除了对 MySQL 5.0 的支持。相反,应该使用 2.0 系列中的最新版本。
在prepare
操作过程中,xtrabackup 会启动一种嵌入其中的修改过的 InnoDB(它所链接的库)。这些修改对于禁用 InnoDB 的标准安全检查是必要的,例如抱怨日志文件的大小不合适,这不适合使用备份。这些修改仅适用于 xtrabackup 二进制文件;您不需要修改过的InnoDB即可使用 xtrabackup 进行备份。
准备步骤使用此嵌入式 InnoDB使用复制的日志文件对复制的数据文件执行崩溃恢复。该prepare
步骤使用起来非常简单:您只需运行xtrabackup --prepare
option 并告诉它要准备哪个目录,例如,准备之前进行的备份运行:
$ xtrabackup --prepare --target-dir
=/data/backups/
完成后,您应该会看到一条InnoDB shutdown
带有如下消息的消息,其中的值再次LSN
取决于您的系统:
InnoDB: Shutdown completed; log sequence number 137345046
160906 11:21:01 completed OK!
以下所有准备都不会更改已经准备好的数据文件,您会看到输出显示:
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
不建议在准备备份时中断 xtrabackup 进程,因为这可能会导致数据文件损坏,备份将变得不可用。如果准备过程被中断,则无法保证备份的有效性。
笔记
如果您打算将备份作为进一步增量备份的基础,则应xtrabackup --apply-log-only
在准备备份时使用该选项,否则您将无法对其应用增量备份。有关详细信息,请参阅有关准备 [增量备份] (incremental_backup.md#incremental-backup) 的文档。
恢复备份
警告
在恢复之前需要准备好备份。
$ xtrabackup --copy-back --target-dir
=/data/backups/
如果您不想保存备份,可以使用xtrabackup --move-back
将备份数据移动到datadir
.
如果您不想使用上述任何选项,您可以额外使用 rsync
或cp
恢复文件。
笔记
在datadir
恢复备份之前必须为空。同样重要的是要注意 MySQL 服务器需要在执行还原之前关闭。您无法恢复到datadir
正在运行的 mysqld 实例(导入部分备份时除外)。
rsync
可用于恢复备份的命令示例如下所示:
$ rsync -avrP /data/backup/ /var/lib/mysql/
您应该检查恢复的文件是否具有正确的所有权和权限。
由于将保留文件的属性,因此在大多数情况下,您需要mysql
在启动数据库服务器之前将文件的所有权更改为,因为它们将归创建备份的用户所有:
$ chown -R mysql:mysql /var/lib/mysql
现在数据已恢复,您可以启动服务器。
笔记
启用后relay-log-info-repository=TABLE
,从备份中恢复的实例在错误日志中有错误,如下所示:
2019-08-09
12:40:02
69297[
ERROR
]Failed to open the relay log
'/data/mysql-relay-bin.004349'(
relay_log_pos
5534092)
要避免这些类型的问题,relay_log_recovery
请RESET SLAVE
在CHANGE MASTER TO
.
中继日志信息已备份,但已创建新的中继日志,这会在还原期间造成不匹配。
增量备份
xtrabackup 工具和 innobackupex 工具都支持增量备份。增量备份仅备份自上次备份以来已更改的数据。
您可以在每个完整备份之间进行多个增量备份。例如,您可以每周进行一次完整备份,每天进行一次增量备份,或者每天进行一次完整备份,每小时进行一次增量备份。
增量备份之所以有效,是因为每个InnoDB页面都包含一个日志序列号 (LSN)。LSN
是整个数据库的系统版本号。每个页面都LSN
显示了它最近的更改时间。
增量备份复制LSN
比先前增量或完整备份更新的每个页面LSN
。有两种算法用于查找要复制的此类页面集。第一个适用于所有服务器类型和版本,LSN
通过读取所有数据页面直接检查页面。第二个,可用于Percona Server for MySQL,启用更改页面跟踪 服务器上的功能,它将在页面被更改时记录下来。然后,该信息将被写在一个紧凑的单独的所谓位图文件中。xtrabackup 二进制文件使用该文件仅读取增量备份所需的数据页。此功能可能会节省许多读取请求。如果 xtrabackup 二进制文件找到位图文件,则默认启用后一种算法。xtrabackup --incremental-force-scan
即使位图数据可用,也可以指定 读取所有页面。
重要的
增量备份不会将数据文件与之前备份的数据文件进行比较。因此,在部分备份之后运行增量备份可能会导致数据不一致。
增量备份读取页面并将其LSN
与上次备份的LSN
. 您必须拥有完整备份才能恢复增量更改。如果没有完整备份作为基础,增量备份将毫无用处。
如果您--incremental-lsn
知道它的LSN
.
另请参阅:部分备份
创建增量备份
要进行增量备份,请像往常一样从完整备份开始。xtrabackup 二进制文件将调用的文件写入xtrabackup_checkpoints
备份的目标目录。该文件包含一行显示 to_lsn
,这是LSN
备份结束时的数据库。 使用以下命令创建完整备份:
$ xtrabackup --backup --target-dir
=/data/backups/base
如果您查看 xtrabackup_checkpoints 文件,您应该会看到类似的内容,具体取决于您的 LSN nuber:
backup_type = full-backuped
from_lsn = 0
to_lsn = 1626007
last_lsn = 1626007
compact = 0
recover_binlog_info = 1
现在您有了完整备份,您可以根据它进行增量备份。使用以下命令:
$ xtrabackup --backup --target-dir
=/data/backups/inc1
\
--incremental-basedir
=/data/backups/base
/data/backups/inc1/ 目录现在应该包含 delta 文件,例如 ibdata1.delta 和 test/table1.ibd.delta。这些代表了自LSN 1626007
. 如果您检查 xtrabackup_checkpoints
此目录中的文件,您应该会看到与以下类似的内容:
backup_type = incremental
from_lsn = 1626007
to_lsn = 4124244
last_lsn = 4124244
compact = 0
recover_binlog_info = 1
from_lsn
是备份的起始 LSN,对于增量备份,它必须与to_lsn
前一个/基本备份的(如果它是最后一个检查点)相同。
现在可以将此目录用作另一个增量备份的基础:
$ xtrabackup --backup --target-dir
=/data/backups/inc2
\
--incremental-basedir
=/data/backups/inc1
此文件夹还包含xtrabackup_checkpoints
:
backup_type = incremental
from_lsn = 4124244
to_lsn = 6938371
last_lsn = 7110572
compact = 0
recover_binlog_info = 1
笔记
to_lsn
在这种情况下,您可以看到(最后一个检查点 LSN)和(最后一个复制的 LSN)之间存在差异last_lsn
,这意味着在备份过程中服务器上有一些流量。
准备增量备份
增量备份的xtrabackup --prepare
步骤与完整备份的步骤不同。在完整备份中,执行两种类型的操作来使数据库保持一致:已提交的事务从日志文件中针对数据文件重放,未提交的事务则回滚。在准备增量备份时,您必须跳过未提交事务的回滚,因为在备份时未提交的事务可能正在进行中,并且很可能会在下一次增量备份中提交。您应该使用 xtrabackup--apply-log-only
选项来防止回滚阶段。
笔记
如果您不使用该 xtrabackup --apply-log-only
选项来阻止回滚阶段,那么您的增量备份将毫无用处。事务回滚后,将无法应用进一步的增量备份。
从您创建的完整备份开始,您可以对其进行准备,然后对其应用增量差异。回想一下,您有以下备份:
/data/backups/base
/data/backups/inc1
/data/backups/inc2
要准备基本备份,您需要像往常一样运行 xtrabackup –prepare,但要防止回滚阶段:
$ xtrabackup --prepare --apply-log-only --target-dir
=/data/backups/base
输出应以类似于以下内容的文本结尾:
InnoDB: Shutdown completed; log sequence number 1626007
161011 12:41:04 completed OK!
日志序列号应与to_lsn
您之前看到的基本备份的序列号相匹配。
笔记
即使操作跳过了回滚阶段,此备份也可以安全地恢复。如果你恢复它并启动MySQL,InnoDB会检测到回滚阶段没有执行,它会在后台执行。此操作与启动时的崩溃恢复相同。此外,MySQL 会通知您数据库未正常关闭。
要将第一个增量备份应用于完整备份,请运行以下命令:
$ xtrabackup --prepare --apply-log-only --target-dir
=/data/backups/base
\
--incremental-dir
=/data/backups/inc1
这会将增量文件应用于 中的文件/data/backups/base
,从而及时将它们前滚到增量备份的时间。然后它像往常一样将重做日志应用于结果。最终数据在 中 /data/backups/base
,而不是在增量目录中。您应该看到类似于以下内容的输出:
incremental backup from
1626007is enabled.
xtrabackup:
cdto /data/backups/base
xtrabackup: This target seems to be already prepared with --apply-log-only.
xtrabackup: xtrabackup_logfile detected:
size=2097152,
start_lsn=(4124244)
...
xtrabackup: page size
for/tmp/backups/inc1/ibdata1.delta is
16384bytes
Applying /tmp/backups/inc1/ibdata1.delta to ./ibdata1...
...
16101112
:45:56 completed OK!
同样,LSN 应该与您之前检查第一次增量备份时看到的一致。如果从 中恢复文件 /data/backups/base
,您应该会看到数据库在第一次增量备份时的状态。
警告
Percona XtraBackup 不支持使用同一个增量备份目录准备两份备份。不要多次xtrabackup --prepare
使用同一个增量备份目录(的值--incremental-dir
)运行。
准备第二次增量备份是一个类似的过程:将增量应用于(修改的)基础备份,您将及时将其数据前滚到第二次增量备份的点:
$ xtrabackup --prepare --target-dir
=/data/backups/base
\
--incremental-dir
=/data/backups/inc2
笔记
xtrabackup --apply-log-only
合并除最后一个以外的所有增量时应使用。这就是前一行不包含 xtrabackup--apply-log-only
选项的原因。即使xtrabackup --apply-log-only
在最后一步使用了,备份仍然是一致的,但在这种情况下,服务器将执行回滚阶段。
准备好后,增量备份与完整备份相同,并且可以以相同的方式恢复。
压缩备份
Percona XtraBackup支持压缩备份:可以使用 xbstream 压缩或解压缩本地或流式备份。
创建压缩备份
为了进行压缩备份,您需要使用 xtrabackup –compress 选项:
$ xtrabackup --backup --compress --target-dir
=/data/compressed/
使用可以通过包配置工具安装的xtrabackup --compress
工具如下:qpresspercona-release
$ sudo percona-release
enabletools
$ sudo apt update
$ sudo apt install qpress
笔记
启用存储库:percona-release enable-only tools release
。如果您打算将 Percona XtraBackup 与上游 MySQL Server 结合使用,您只需要启用tools
存储库:percona-release enable-only tools
.
如果要加快压缩速度,可以使用并行压缩,可以使用 xtrabackup –compress-threads 选项启用。以下示例将使用四个线程进行压缩:
$ xtrabackup --backup --compress --compress-threads
=4\
--target-dir
=/data/compressed/
输出应如下所示
...
170223 13:00:38 [01] Compressing ./test/sbtest1.frm to /tmp/compressed/test/sbtest1.frm.qp
170223 13:00:38 [01] ...done
170223 13:00:38 [01] Compressing ./test/sbtest2.frm to /tmp/compressed/test/sbtest2.frm.qp
170223 13:00:38 [01] ...done
...
170223 13:00:39 [00] Compressing xtrabackup_info
170223 13:00:39 [00] ...done
xtrabackup: Transaction log of lsn (9291934) to (9291934) was copied.
170223 13:00:39 completed OK!
准备备份
在准备备份之前,您必须解压缩所有文件。 Percona XtraBackup已实现xtrabackup --decompress
可用于解压缩备份的选项。
$ xtrabackup --decompress --target-dir
=/data/compressed/
笔记
xtrabackup --parallel
可以与xtrabackup --decompress
选项一起使用以同时解压缩多个文件。
Percona XtraBackup不会自动删除压缩文件。为了清理备份目录,请使用该 xtrabackup --remove-original
选项。如果文件未删除,则不会将它们复制或移动到数据目录(如果 使用xtrabackup --copy-back
或xtrabackup --move-back
使用)。
解压缩文件后,您可以使用以下 xtrabackup --prepare
选项准备备份:
$ xtrabackup --prepare --target-dir
=/data/compressed/
检查确认消息:
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 9293846
170223 13:39:31 completed OK!
现在,其中的文件/data/compressed/
已准备好供服务器使用。
恢复备份
xtrabackup 有一个xtrabackup --copy-back
选项,可以将备份恢复到服务器的 datadir:
$ xtrabackup --copy-back --target-dir
=/data/backups/
该选项将所有与数据相关的文件复制回服务器datadir
,由服务器的my.cnf
配置文件确定。检查输出的最后一行以获取成功消息:
170223 13:49:13 completed OK!
将数据复制回来后验证文件权限。您可能需要调整权限。例如,以下命令更改文件位置的所有者:
$ chown -R mysql:mysql /var/lib/mysql
现在datadir
包含恢复的数据。您已准备好启动服务器。
加密备份
Percona XtraBackup已实现对加密备份的支持。它可用于使用 xbstream 选项加密/解密本地或流式备份(不支持流式 tar 备份),以便为备份添加另一层保护。加密是通过libgcrypt
库完成的。
创建加密备份
要进行加密备份,需要指定以下选项(选项 xtrabackup --encrypt-key
和xtrabackup --encrypt-key-file
是互斥的,即只需要提供其中一个):
--encrypt=ALGORITHM
- 当前支持的算法是AES128
:AES192
和AES256
--encrypt-key=ENCRYPTION_KEY
- 要使用的适当长度的加密密钥。不建议在对机器进行不受控制的访问的情况下使用此选项作为命令行,因此可以将密钥视为进程信息的一部分。--encrypt-key-file=KEYFILE
- 可以从中读取适当长度的原始密钥的文件的名称。该文件必须是一个简单的二进制(或文本)文件,其中包含要使用的密钥。
xtrabackup --encrypt-key
option 和 option都xtrabackup --encrypt-key-file
可以用来指定加密密钥。可以使用以下命令生成加密密钥:
$ openssl rand -base64
24
该命令的示例输出应如下所示:
GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs
然后可以将该值用作加密密钥
使用--encrypt-key
选项
使用 xtrabackup 命令的示例xtrabackup --encrypt-key
应如下所示:
$ xtrabackup --backup --target-dir
=/data/backups --encrypt
=AES256
\
--encrypt-key
="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs"
使用--encrypt-key-file
选项
使用 xtrabackup 命令的示例 xtrabackup --encrypt-key-file
应如下所示:
$ xtrabackup --backup --target-dir
=/data/backups/ --encrypt
=AES256
\
--encrypt-key-file
=/data/backups/keyfile
笔记
根据用于制作的文本编辑器KEYFILE
,在某些情况下,文本文件可能包含 CRLF,这将导致密钥大小增加,从而使其无效。建议的方法是使用以下命令创建文件:echo -n "GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" > /data/backups/keyfile
优化加密过程
加密备份引入了两个选项,可用于加速加密过程。这些是 xtrabackup --encrypt-threads
和 xtrabackup --encrypt-chunk-size
。通过使用该 xtrabackup --encrypt-threads
选项,可以指定多个线程用于并行加密。选项xtrabackup --encrypt-chunk-size
可用于指定每个加密线程的工作加密缓冲区的大小(以字节为单位)(默认为 64K)。
解密加密备份
Percona XtraBackup xtrabackup --decrypt
选项已实现,可用于解密备份:
$ xtrabackup --decrypt
=AES256 --encrypt-key
="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs"\
--target-dir
=/data/backups/
Percona XtraBackup不会自动删除加密文件。为了清理备份目录,用户应该删除 *.xbcrypt 文件。在Percona XtraBackup 2.4.6xtrabackup --remove-original
中实现了选项,一旦加密文件被解密,您就可以使用它来删除它们。要在解密后删除文件,您应该运行:
$ xtrabackup --decrypt
=AES256 --encrypt-key
="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs"\
--target-dir
=/data/backups/ --remove-original
笔记
xtrabackup --parallel
可以与xtrabackup --decrypt
选项一起使用同时解密多个文件。
当文件被解密后,就可以准备备份了。
准备加密备份
备份解密后,可以使用与标准完整备份相同的方式准备它们,并带有以下xtrabackup --prepare
选项:
$ xtrabackup --prepare --target-dir
=/data/backups/
恢复加密备份
xtrabackup 有一个xtrabackup --copy-back
选项,可以将备份恢复到服务器的 datadir:
$ xtrabackup --copy-back --target-dir
=/data/backups/
它将所有与数据相关的文件复制回服务器的datadir
,由服务器的my.cnf
配置文件决定。您应该检查输出的最后一行以获取成功消息:
170214 12:37:01 completed OK!
其他阅读
Percona XtraBackup 用户手册
Percona XtraBackup是一组以下工具:
innobackupex is the symlink for *xtrabackup*. innobackupex still
supports all features and syntax as 2.2 version did, but is now
deprecated and will be removed in next major release.
a compiled *C* binary that provides functionality to backup a whole *MySQL*
database instance with *MyISAM*, *InnoDB*, and XtraDB tables.
utility used for encrypting and decrypting backup files.
utility that allows streaming and extracting files to/from the
xbstream format.
utility used for downloading and uploading full or part of xbstream
archive from/to cloud.
Percona XtraBackup 2.3 发布后,推荐的备份方法是使用xtrabackup脚本。有关脚本选项的更多信息,请参阅如何使用 xtrabackup。
限制备份
尽管 xtrabackup 不会阻止您的数据库操作,但任何备份都可能给正在备份的系统增加负载。在没有太多备用 I/O 容量的系统上,限制 xtrabackup 读取和写入数据的速率可能会有所帮助。您可以使用该xtrabackup --throttle
选项执行此操作。此选项限制每秒复制的块数。块大小为10 MB。
下图显示了xtrabackup --throttle
设置为 1 时节流的工作方式。
默认情况下没有节流,xtrabackup 以最快的速度读写数据。如果对 IOPS 设置的限制太严格,备份可能会变慢,以至于它永远无法赶上 InnoDB 正在写入的事务日志,并且备份可能永远不会完成。
无锁二进制日志信息
此功能是Percona Server for MySQL独有的,从版本 5.6.26-74.0 开始。当节点在没有xtrabackup --galera-info
.
当服务器上的Lockless 二进制日志信息 功能可用时,Percona XtraBackup可以信任存储在InnoDB系统标头中的二进制日志信息,并在多种情况下避免执行 (因此,在完成日志副本LOCK BINLOG FOR BACKUP
期间阻止提交):REDO
- 当服务器不是启用 GTID 的 Galera 集群节点时
- 当复制 I/O 线程信息不应作为备份的一部分存储时(即
xtrabackup --slave-info
未指定选项时)
如果以上所有条件都成立,Percona XtraBackup不会SHOW MASTER STATUS
作为备份过程的一部分执行,也不会xtrabackup_binlog_info
在备份时创建文件。相反,在准备备份之后检索该信息并创建文件,以及创建xtrabackup_binlog_pos_innodb
,在这种情况下,它包含与 in 完全相同的信息,xtrabackup_binlog_info
因此是多余的。
为了使这个新功能可配置,现在有一个新的Percona XtraBackup选项xtrabackup --binlog-info
,它可以接受以下值:
OFF
- 这意味着Percona XtraBackup根本不会尝试检索二进制日志信息,无论是在备份创建期间还是在准备备份之后。当用户只想复制没有任何元信息(如二进制日志或复制坐标)的数据时,这会有所帮助。在这种情况下,xtrabackup --binlog-info=OFF
可以传递给Percona XtraBackup并且LOCK BINLOG FOR BACKUP
不会被执行,即使服务器没有提供备份安全的 binlog info 功能(但备份锁功能仍然是一个要求)。ON
- 这与旧行为相匹配,即实施此Percona XtraBackup功能之前的行为。指定时,Percona XtraBackup检索二进制日志信息并使用LOCK BINLOG FOR BACKUP
(如果可用)以确保其一致性。LOCKLESS
- 这对应于上面解释的功能: Percona XtraBackup在备份过程中不会检索二进制日志信息,不会执行LOCK BINLOG FOR BACKUP
,xtrabackup_binlog_info
也不会创建文件。该文件将在使用存储在 InnoDB 系统标头中的信息准备备份后创建。如果服务器未提供所需的服务器端功能,则指定此xtrabackup --binlog-info
值将导致错误。如果上述条件之一不成立,LOCK BINLOG FOR BACKUP
仍会执行以保证其他元数据的一致性。AUTO
- 这是默认值。使用时,Percona XtraBackup将根据服务器端功能的可用性(即 服务器变量是否可用)自动切换到ON
or 或。LOCKLESShave_backup_safe_binlog_info
加密的 InnoDB 表空间备份
从MySQL 5.7.11 开始,InnoDB 支持 存储在 file-per-table 表空间中的 InnoDB 表的数据加密。此功能为物理表空间数据文件提供静态加密。
对于经过身份验证的用户或应用程序访问加密的表空间,InnoDB 将使用主加密密钥来解密表空间密钥。主加密密钥存储在密钥环中。xtrabackup 支持的两个密钥环插件是keyring_file
和keyring_vault
. 这些插件安装在插件目录中。
keyring_file
使用插件进行备份
Percona XtraBackup 2.4.2 通过实现选项(以及5.7.13 之前的MySQL需要的选项)keyring_file
实现了对加密 InnoDB 表空间备份的支持。这些选项只能被 xtrabackup 二进制识别,即 innobackupex 将无法备份和准备加密表空间。xtrabackup --keyring-file-dataxtrabackup --server-id
创建备份
为了备份和准备包含加密 InnoDB 表空间的数据库,您必须使用该xtrabackup --keyring-file-data
选项指定密钥环文件的路径。
$ xtrabackup --backup --target-dir
=/data/backup/ --user
=root
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
对于5.7.13 之前的 MySQL,在xtrabackup --server-id
备份创建命令中使用:
$ xtrabackup --backup --target-dir
=/data/backup/ --user
=root
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring --server-id
=1
在 xtrabackup 完成备份后,您应该会看到以下消息:
xtrabackup: Transaction log of lsn
(5696709)to
(5696718)was copied.
16040110
:25:51 completed OK!
警告
xtrabackup 不会将密钥环文件复制到备份目录中。为了准备备份,您必须自己制作密钥环文件的副本。
准备备份
为了准备备份,您需要指定 keyring-file-data(服务器 ID 存储在backup-my.cnf
文件中,因此在准备备份时可以省略它,无论使用的MySQL版本如何)。
xtrabackup --prepare --target-dir
=/data/backup
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
在 xtrabackup 完成备份准备后,您应该会看到以下消息:
InnoDB: Shutdown completed
;log sequence number
5697064
16040110
:34:28 completed OK!
备份现已准备就绪,可以使用 xtrabackup –copy-back 选项进行恢复。如果密钥环已轮换,您需要恢复用于获取和准备备份的密钥环。
keyring_vault
使用插件进行备份
Percona XtraBackup 2.4.11keyring_vault
已实现对加密 InnoDB 表空间备份的支持。Keyring Vault 插件设置在此处描述。
创建备份
以下命令在/data/backup
目录中创建备份:
$ xtrabackup --backup --target-dir
=/data/backup --user
=root
xtrabackup 完成备份后,您应该会看到以下消息:
xtrabackup: Transaction log of lsn
(5696709)to
(5696718)was copied.
16040110
:25:51 completed OK!
准备备份
为了准备备份,xtrabackup 需要访问密钥环。由于 xtrabackup 不与 MySQL 服务器对话,并且 my.cnf
在准备期间不读取默认配置文件,因此用户需要通过命令行指定密钥环设置:
$ xtrabackup --prepare --target-dir
=/data/backup
\
--keyring-vault-config
=/etc/vault.cnf
也可以看看
Percona 服务器的静态数据加密 [keyring vault 插件设置] (https://www.percona.com/doc/percona-server/LATEST/management/data_at_rest_encryption.html#keyring-vault-plugin)。
在 xtrabackup 完成备份准备后,您应该会看到以下消息:
InnoDB: Shutdown completed
;log sequence number
5697064
16040110
:34:28 completed OK!
备份现已准备就绪,可以使用以下xtrabackup --copy-back
选项恢复:
xtrabackup --copy-back --target-dir
=/data/backup --datadir
=/data/mysql
增量加密 InnoDB 表空间备份keyring_file
使用 InnoDB 表空间加密进行增量备份的过程类似于使用未加密表空间进行增量备份。
创建增量备份
要进行增量备份,请从完整备份开始。xtrabackup 二进制文件将调用的文件写入xtrabackup_checkpoints
备份的目标目录。该文件包含一行显示to_lsn
,这是LSN
备份结束时的数据库。首先,您需要使用以下命令创建完整备份:
$ xtrabackup --backup --target-dir
=/data/backups/base
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
警告
xtrabackup 不会将密钥环文件复制到备份目录中。为了准备备份,您必须自己制作密钥环文件的副本。如果您在更改密钥环后尝试恢复备份,您将看到ERROR 3185 (HY000): Can't find master key from keyring, please check keyring plugin is loaded.
尝试访问加密表时出现的错误。
如果您查看该xtrabackup_checkpoints
文件,您应该会看到类似于以下内容的一些内容:
backup_type = full-backuped
from_lsn = 0
to_lsn = 7666625
last_lsn = 7666634
compact = 0
recover_binlog_info = 1
现在您有了完整备份,您可以根据它进行增量备份。使用如下命令:
$ xtrabackup --backup --target-dir
=/data/backups/inc1
\
--incremental-basedir
=/data/backups/base
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
警告
xtrabackup 不会将密钥环文件复制到备份目录中。为了准备备份,您必须自己制作密钥环文件的副本。如果密钥环尚未轮换,您可以使用与您使用基本备份备份的密钥环相同的密钥环。如果密钥环已轮换,您需要备份它,否则您将无法准备备份。
该/data/backups/inc1/
目录现在应该包含增量文件,例如ibdata1.delta
和test/table1.ibd.delta
。这些代表了自LSN 7666625
. 如果您检查 xtrabackup_checkpoints
此目录中的文件,您应该会看到类似于以下内容的内容:
backup_type = incremental
from_lsn = 7666625
to_lsn = 8873920
last_lsn = 8873929
compact = 0
recover_binlog_info = 1
意义应该是不言而喻的。现在可以将此目录用作另一个增量备份的基础:
$ xtrabackup --backup --target-dir
=/data/backups/inc2
\
--incremental-basedir
=/data/backups/inc1
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
准备增量备份
增量备份的xtrabackup --prepare
步骤与普通备份的步骤不同。在正常备份中,执行两种类型的操作以使数据库保持一致:从日志文件中针对数据文件重放已提交的事务,以及回滚未提交的事务。准备备份时必须跳过未提交事务的回滚,因为在备份时未提交的事务可能正在进行中,并且很可能会在下一次增量备份中提交。您应该使用该xtrabackup --apply-log-only
选项来防止回滚阶段。
警告
如果您不使用该xtrabackup --apply-log-only
选项来阻止回滚阶段,那么您的增量备份将毫无用处。事务回滚后,无法应用进一步的增量备份。
从您创建的完整备份开始,您可以对其进行准备,然后对其应用增量差异。回想一下,您有以下备份:
/data/backups/base
/data/backups/inc1
/data/backups/inc2
要准备基本备份,您需要xtrabackup --prepare
照常运行,但要防止回滚阶段:
$ xtrabackup --prepare --apply-log-only --target-dir
=/data/backups/base
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
输出应以一些文本结尾,如下所示:
InnoDB: Shutdown completed
;log sequence number
7666643
InnoDB: Number of pools:
1
16040112
:31:11 completed OK!
要将第一个增量备份应用于完整备份,您应该使用以下命令:
$ xtrabackup --prepare --apply-log-only --target-dir
=/data/backups/base
\
--incremental-dir
=/data/backups/inc1
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
警告
应使用进行备份时使用的密钥环来准备备份。这意味着如果密钥环已在基本备份和增量备份之间轮换,您将需要使用第一次增量备份时正在使用的密钥环。
准备第二次增量备份是一个类似的过程:将增量应用于(修改的)基础备份,您将及时将其数据前滚到第二次增量备份的点:
$ xtrabackup --prepare --target-dir
=/data/backups/base
\
--incremental-dir
=/data/backups/inc2
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
笔记
--apply-log-only
合并除最后一个之外的每个增量备份时应使用xtrabackup 。这就是为什么上一行不包含xtrabackup --apply-log-only
. 即使xtrabackup --apply-log-only
在最后一步使用了,备份仍然是一致的,但在这种情况下,服务器将执行回滚阶段。
备份现已准备就绪,可以使用xtrabackup --copy-back
. 如果密钥环已轮换,您需要恢复用于获取和准备备份的密钥环。
密钥环不可用时恢复备份
虽然所描述的恢复方法有效,但它需要访问服务器正在使用的相同密钥环。如果备份是在不同的服务器上准备的,或者在很久以后,当密钥环中的密钥被清除时,或者在密钥环库服务器根本不可用时发生故障,则可能无法进行备份。
应该使用Axtrabackup --transition-key
使 xtrabackup 可以在不访问密钥环保险库服务器的情况下处理备份。在这种情况下,xtrabackup 将从指定的密码短语派生 AES 加密密钥,并将使用它来加密正在备份的表空间的表空间密钥。
使用密码创建备份
以下示例说明了在这种情况下如何创建备份:
$ xtrabackup --backup --user
=root -p --target-dir
=/data/backup
\
--transition-key
=MySecretKey
如果xtrabackup --transition-key
没有指定值,xtrabackup 将要求它。
笔记
xtrabackup --transition-key
刮掉提供的值,使其不会出现在ps
命令输出中。
使用密码准备备份
应为prepare
命令指定相同的密码:
$ xtrabackup --prepare --target-dir
=/data/backup
\
--transition-key
=MySecretKey
这里没有keyring-vault
or keyring-file
,因为在这种情况下 xtrabackup 不与密钥环对话。
使用生成的密钥恢复备份
恢复备份时,您需要生成新的主密钥。这是示例keyring_file
:
$ xtrabackup --copy-back --target-dir
=/data/backup --datadir
=/data/mysql
\
--transition-key
=MySecetKey --generate-new-master-key
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
如果keyring_vault
它看起来像这样:
$ xtrabackup --copy-back --target-dir
=/data/backup --datadir
=/data/mysql
\
--transition-key
=MySecetKey --generate-new-master-key
\
--keyring-vault-config
=/etc/vault.cnf
xtrabackup 将生成新的主密钥,将其存储到目标密钥环保险库服务器并使用此密钥重新加密表空间密钥。
使用存储的转换密钥进行备份
最后,可以选择将转换密钥存储在密钥环中。在这种情况下,xtrabackup 将需要在准备和复制期间访问相同的密钥环文件或保管库服务器,但不取决于服务器密钥是否已被清除。
备份过程的三个阶段如下:
备份
$ xtrabackup --backup --user
=root -p --target-dir
=/data/backup
\
--generate-transition-key
准备
keyring_file
变体
$ xtrabackup --prepare --target-dir
=/data/backup
\
--keyring-file-data
=/var/lib/mysql-keyring/keyring
keyring_vault
变体
$ xtrabackup --prepare --target-dir
=/data/backup
\
--keyring-vault-config
=/etc/vault.cnf
复制回
keyring_file
变体
$ xtrabackup --copy-back --target-dir
=/data/backup --datadir
=/data/mysql
\
--generate-new-master-key --keyring-file-data
=/var/lib/mysql-keyring/keyring
keyring_vault
变体
$ xtrabackup --copy-back --target-dir
=/data/backup --datadir
=/data/mysql
\
--generate-new-master-key --keyring-vault-config
=/etc/vault.cnf
lock-ddl-per-table
选项改进
MySQL 5.7 对批量加载进行了改进,其中一项改进是能够禁用重做日志记录,从而提高了 ADD INDEX 操作的速度。
为了阻止实例上的 DDL 语句,Percona Server 实现了 LOCK TABLES FOR BACKUP。Percona XtraBackup在备份期间使用此锁。此锁不影响 DML 语句。
Percona XtraBackup也实现--lock-ddl-per-table
了,它通过使用元数据锁 (MDL) 来阻止 DDL 语句。
以下过程描述了使用 时的简化备份操作 --lock-ddl-per-table
:
- 解析并复制检查点标记后的所有重做日志
- 派生一个专用线程以继续跟踪新的重做日志条目
- 列出复制所需的表空间
- 遍历列表。每个列出的表空间都会发生以下步骤:
- 查询 INFORMATION_SCHEMA.INNODB_SYS_TABLES 以查找哪些表属于表空间 ID,并在基础表或表上获取 MDL,以防存在共享表空间。
- 复制表空间
.ibd
文件。
备份过程可能会遇到由批量加载操作生成的重做日志事件,该事件会通知备份工具数据文件更改已从重做日志中省略。本次活动是一个MLOG_INDEX_LOAD
。如果重做跟随线程发现此事件,则备份继续并假定备份是安全的,因为 MDL 保护已复制的表空间,并且该MLOG_INDEX_LOAD
事件针对未复制的表空间。
这些假设可能不正确,并可能导致备份不一致。
--lock-ddl-per-table
重新设计
在Percona XtraBackup版本 2.4.21 中实施, --lock-ddl-per-table
经过重新设计以最大限度地减少不一致的备份。以下过程对步骤进行了重新排序:
- 在备份开始时获取 MDL 锁
- 扫描重做日志。如果在备份开始之前发生
MLOG_INDEX_LOAD
了语句,则可能会记录一个事件。CREATE INDEX
此时,备份过程是安全的,可以解析并接受事件。 - 第一次扫描完成后,将启动后续重做日志线程,如果发现事件,该线程将停止备份过程
MLOG_INDEX_LOAD
。 - 收集要复制的表空间列表
- 复制
.ibd
文件。
其他改进
添加了以下改进:
- 如果
.ibd
文件属于临时表,SELECT
则跳过查询。 - 对于全文索引,在基表上获取 MDL。
SELECT
获取 MDL的查询不检索数据。- 进行本地完整备份(创建、准备和恢复)
- 制作流媒体备份
- 进行增量备份
- 制作压缩备份
- 备份和恢复单个分区
- 进行完整备份
- 进行增量备份
- 恢复备份
- 如何使用 Percona XtraBackup 通过 6 个简单步骤设置复制副本
- 使用复制和 pt-checksum 验证备份
- 如何创建一个新的(或修复损坏的)基于 GTID 的从站
- 启用服务器通过 TCP/IP 进行通信
- 用户的特权和权限
- 安装和配置 SSH 服务器
操作方法和食谱
innobackupex 的食谱
xtrabackup的食谱
操作方法
辅助指南
本节中的假设
上下文应该使食谱或教程易于理解。为确保这是真的,列出了本节中出现的假设、名称和其他对象。这些项目在每个食谱或教程的开头指定。
HOST
安装、配置和运行基于MySQL的服务器的系统。我们对这个系统假设如下:
- MySQL 服务器可以通过标准的 TCP/IP 端口与其他服务器进行通信;
- 已安装并配置了 SSH 服务器 -如果没有,请参见此处;
- 您在系统中有一个具有适当权限的用户帐户
- 您有一个 MySQL 的用户帐户,具有适当的Connection 和 Privileges Needed。
USER
这是具有 shell 访问权限和任务相应权限的用户帐户。检查它们的指南在这里。
DB-USER
这是数据库服务器中具有任务相应权限的用户帐户。检查它们的指南在这里。
Percona XtraBackup 2.4 发行说明
- Percona XtraBackup 2.4.26 (2022-05-09)
- Percona XtraBackup 2.4.25 (2022-04-16)
- Percona XtraBackup 2.4.24 (2021-09-14)
- Percona XtraBackup 2.4.23 (2021-06-22)
- Percona XtraBackup 2.4.22 (2021-03-22)
- Percona XtraBackup 2.4.21 (2020-11-12)
- Percona XtraBackup 2.4.20 (2020-04-14)
- Percona XtraBackup 2.4.19 (2020-03-25)
- Percona XtraBackup 2.4.18 (2019-12-16)
- Percona XtraBackup 2.4.17 (2019-12-09)
- Percona XtraBackup 2.4.16 (2019-11-04)
- Percona XtraBackup 2.4.15 (2019-07-10)
- Percona XtraBackup 2.4.14 (2019-05-01)
- Percona XtraBackup 2.4.13 (2019-01-18)
- Percona XtraBackup 2.4.12 (2018-06-22)
- Percona XtraBackup 2.4.11 (2018-04-23)
- Percona XtraBackup 2.4.10 (2018-03-30)
- Percona XtraBackup 2.4.9 (2017-11-29)
- Percona XtraBackup 2.4.8 (2017-07-24)
- Percona XtraBackup 2.4.7-2 (2017-05-29)
- Percona XtraBackup 2.4.7 (2017-04-17)
- Percona XtraBackup 2.4.6 (2017-02-22)
- Percona XtraBackup 2.4.5 (2016-11-29)
- Percona XtraBackup 2.4.4 (2016-07-25)
- Percona XtraBackup 2.4.3 (2016-05-23)
- Percona XtraBackup 2.4.2 (2016-04-01)
- Percona XtraBackup 2.4.1 (2016-02-16)
xtrabackup 选项参考
xtrabackup
此页面记录了二进制文件的所有命令行选项 。
选项
--apply-log-only
此选项仅导致在准备备份时执行重做阶段。这对于增量备份非常重要。
--备份
做一个备份并将其放入xtrabackup --target-dir
. 请参阅 创建备份。
--备份锁定重试计数=
尝试获取元数据锁的次数。
--备份锁定超时=
尝试获取元数据锁的超时时间(以秒为单位)。
--binlog-信息
此选项控制Percona XtraBackup应如何检索与备份对应的服务器二进制日志坐标。可能的值为 OFF
、ON
和。有关更多信息,请参阅Percona XtraBackup Lockless 二进制日志信息 手册页。LOCKLESSAUTO
--检查权限
此选项检查Percona XtraBackup是否具有所有必需的权限。如果当前操作需要缺少权限,它将终止并打印出错误消息。如果当前操作不需要缺少的特权,但某些其他 XtraBackup 操作可能需要缺少特权,则不会中止该过程,并打印警告。
xtrabackup: Error: missing required privilege LOCK TABLES on *.*
xtrabackup: Warning: missing required privilege REPLICATION CLIENT on *.*
--关闭文件
不要让文件保持打开状态。当xtrabackup打开一个表空间时,它通常不会关闭其文件句柄以正确管理 DDL 操作。但是,如果表空间的数量很大并且无法满足任何限制,则可以选择在不再访问文件句柄时关闭它们。Percona XtraBackup可以在启用此选项的情况下生成不一致的备份。使用该选项需要您自担风险。
-袖珍的
通过跳过二级索引页创建紧凑备份。
-压缩
此选项告诉xtrabackup使用指定的压缩算法压缩所有输出数据,包括事务日志文件和元数据文件。当前唯一支持的算法是quicklz
. 生成的文件具有 qpress 存档格式。
xtrabackup 生成的每个\*.qp
文件本质上都是一个单文件 qpress 存档,并且可以由qpress 文件存档器提取和解压缩。
--压缩块大小=
压缩线程的工作缓冲区大小(以字节为单位)。默认值为 64K。
--压缩线程=
此选项指定xtrabackup用于并行数据压缩的工作线程数。此选项默认为1
。并行压缩 ( xtrabackup --compress-threads
) 可以与并行文件复制 ( xtrabackup --parallel
) 一起使用。例如, --parallel=4 --compress --compress-threads=2
将创建 4 个 I/O 线程来读取数据并将其通过管道传输到 2 个压缩线程。
– 复制回
将先前制作的备份中的所有文件从备份目录复制到其原始位置。除非指定选项,否则此选项不会复制现有文件xtrabackup --force-non-empty-directories
。
--核心文件
在致命信号上写入核心。
--数据库=
此选项指定应备份的数据库和表的列表。该选项接受表单的列表"databasename1[.table_name1] databasename2[.table_name2] . . ."
。
--databases-exclude=name
根据名称排除数据库。此选项的操作方式与 相同xtrabackup --databases
,但从备份中排除匹配的名称。请注意,此选项的优先级高于 xtrabackup --databases
。
--数据库文件=
此选项指定包含应备份的数据库和表列表的文件的路径。该文件可以包含表单的列表元素,databasename1[.table_name1]
每行一个元素。
--datadir=目录
备份的源目录。这个目录应该和你的MySQL服务器的 datadir 相同,如果存在的话,应该从 my.cnf 中读取;否则,您必须在命令行中指定它。
与xtrabackup --copy-back
or xtrabackup --move-back
选项结合使用时,xtrabackup --datadir
指的是目标目录。
连接到服务器后,要执行备份,您将需要 服务器数据目录中文件系统级别READ
的EXECUTE
权限。
--debug-sleep-before-unlock=
Xtrabackup 测试套件使用的仅调试选项。
--解压
此选项解压缩.qp
先前使用该xtrabackup --compress
选项创建的备份中扩展名为的所有文件。该 xtrabackup --parallel
选项将允许同时解密多个文件。要解压缩,必须安装 qpress 实用程序并可在路径中访问。Percona XtraBackup不会自动删除压缩文件。要清理备份目录,用户应使用该xtrabackup --remove-original
选项。
--decrypt=加密算法
xtrabackup --encrypt
解密先前使用选项制作的备份中所有扩展名为 .xbcrypt 的文件。该 xtrabackup --parallel
选项将允许同时解密多个文件。Percona XtraBackup不会自动删除加密文件。要清理备份目录,用户应该使用xtrabackup --remove-original
option。
--defaults-extra-file=[MY.CNF]
读取全局文件后读取此文件。此文件必须是命令行上的第一个选项。
--defaults-file=[MY.CNF]
仅从给定文件中读取默认选项。该文件必须是命令行的第一个选项,并且是真实文件,不能是符号链接。
--defaults-group=组名
此选项设置应从配置文件中读取的组。该选项由 使用--default-group
并且是必需的
mysqld_multi
部署。
--defaults-组-后缀=
阅读通常的选项组以及带有 concat(group, suffix) 的组。
–dump-innodb-缓冲池
此选项控制是否应进行缓冲池内容的新转储。
使用时,如果状态变量报告转储已完成--dump-innodb-buffer-pool
,xtrabackup 会在备份开始时向服务器发出请求以启动缓冲池转储(需要一些时间才能完成并在后台完成) 。innodb_buffer_pool_dump_status
$ xtrabackup --backup --dump-innodb-buffer-pool --target-dir
=/home/user/backup
默认情况下,此选项设置为关闭。
如果innodb_buffer_pool_dump_status
报告缓冲池正在运行转储,xtrabackup使用 –dump-innodb-buffer-pool-timeout 的值等待转储完成
该文件ib_buffer_pool
存储用于更快预热缓冲池的表空间 ID 和页面 ID 数据。
–dump-innodb-buffer-pool-timeout
此选项包含xtrabackup应监视的值innodb_buffer_pool_dump_status
以确定缓冲池转储是否已完成的秒数。
此选项与 结合使用 --dump-innodb-buffer-pool
。默认情况下,它设置为 10 秒。
–dump-innodb-buffer-pool-pct
此选项包含要转储的最近使用的缓冲池页面的百分比。
如果 –dump-innodb-buffer-pool 选项设置为 ON,则此选项有效。如果此选项包含一个值,xtrabackup将设置MySQL 系统变量innodb_buffer_pool_dump_pct
。一旦缓冲池转储完成或停止(请参阅–dump-innodb-buffer-pool-timeout),MySQL系统变量的值就会恢复。
--encrypt=ENCRYPTION_ALGORITHM
此选项指示 xtrabackup 使用 ENCRYPTION_ALGORITHM 中指定的算法加密 InnoDB 数据文件的备份副本。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅 xtrabackup
文档。
--encrypt-key=ENCRYPTION_KEY
此选项指示 xtrabackupENCRYPTION_KEY
在使用该选项时使用给定的值xtrabackup --encrypt
。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅 xtrabackup 文档。
--encrypt-key-file=ENCRYPTION_KEY_FILE
ENCRYPTION_KEY_FILE
此选项指示 xtrabackup在使用该选项时使用存储在给定中的加密密钥xtrabackup --encrypt
。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅 xtrabackup文档。
--加密线程=
此选项指定将用于并行加密/解密的工作线程数。有关更多详细信息,请参阅 xtrabackup文档。
--加密块大小=
此选项指定每个加密线程的内部工作缓冲区的大小,以字节为单位。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅xtrabackup
文档。
笔记
要在使用加密时调整 xbcloud/xbstream 块大小,必须同时调整 –encrypt-chunk-size 和 –read-buffer-size 变量。
-出口
创建导出表所需的文件。请参阅恢复单个表。
--extra-lsndir=目录
(用于--backup):在此目录中保存xtrabackup_checkpoints
和文件的额外副本。xtrabackup_info
--force-非空目录
指定时,它使 :option`xtrabackup –copy-back` 和 xtrabackup --move-back
选项将文件传输到非空目录。不会覆盖现有文件。如果需要从备份目录复制/移动的文件已经存在于目标目录中,它仍然会失败并出现错误。
--ftwrl-等待超时=秒
此选项以秒为单位指定 xtrabackupFLUSH TABLES WITH READ LOCK
在运行之前应等待会阻塞的查询的时间。如果超时后仍有此类查询,则 xtrabackup 会以错误终止。默认值为0
,在这种情况下,它不会等待查询完成并FLUSH TABLES WITH READ LOCK
立即启动。如果支持(Percona Server 5.6+)xtrabackup 将自动使用备份锁 作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。
--ftwrl-wait-threshold=SECONDS
此选项指定查询运行时间阈值,xtrabackup 使用该阈值检测具有非零值 xtrabackup –ftwrl-wait-timeout 的长时间运行的查询。FLUSH TABLES WITH READ LOCK
在存在此类长时间运行的查询之前不会启动。如果 xtrabackup –ftwrl-wait-timeout 为 ,则此选项无效0
。默认值为60
秒。如果支持(Percona Server 5.6+)xtrabackup 将自动使用备份锁 作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。
–ftwrl-wait-query-type=全部|更新
此选项指定在 xtrabackup 发出全局锁之前允许完成哪些类型的查询。默认值为all
.
–galera信息
此选项创建xtrabackup_galera_info
包含备份时本地节点状态的文件。执行 Percona XtraDB Cluster 备份时应使用选项。当使用备份锁创建备份时,它不起作用。
--generate-new-master-key
执行回写操作时生成新的主密钥。
--历史=名称
此选项启用 PERCONA_SCHEMA.xtrabackup_history
表中备份历史记录的跟踪。可以指定一个可选的历史系列名称,该名称将与正在执行的备份的历史记录一起放置。
-增加的
此选项告诉 xtrabackup 创建增量备份。它被传递给 xtrabackup 子进程。指定此选项时, xtrabackup --incremental-lsn
也可以给出 xtrabackup –incremental-basedir 或 xtrabackup –incremental-basedir。如果两个选项都没有给出,则选项 xtrabackup --incremental-basedir
默认传递给 xtrabackup,设置为备份基目录中的第一个时间戳备份目录。
--incremental-basedir=目录
此目录包含完整备份,它是用于增量备份的基本数据集。
--incremental-dir=目录
准备增量备份时,这是将增量备份与完整备份组合以进行新的完整备份的目录。
-增量力扫描
创建增量备份时,即使完整的更改页位图数据可用,也要强制对要在备份中使用的实例中的数据页进行完整扫描。
--增量历史名称=名称
此选项指定存储在 PERCONA_SCHEMA.xtrabackup_history历史记录中的备份系列的名称,以作为增量备份的基础。xtrabackup在历史表中搜索最近的(最高的 innodb_to_lsn),成功备份系列,并将 to_lsn 值用作增量备份的起始 lsn。这将与 xtrabackup --incremental-history-uuid
和互斥。如果找不到有效的(没有该名称的系列,没有该名称的成功备份)xtrabackup 返回错误。它与 选项一起使用。xtrabackup --incremental-basedirxtrabackup --incremental-lsnLSNxtrabackup --incremental
--innodb-checksum-algorithm=name
InnoDB 用于计算页面校验和的算法。可用的算法有 CRC32、INNODB、NONE、STRICT_CRC32、STRICT_INNODB 和 STRICT_NONE
--incremental-history-uuid=UUID
此选项指定UUID
存储在PERCONA_SCHEMA.xtrabackup_historyxtrabackup --incremental-history-name
中的特定历史记录, 以基于xtrabackup --incremental-basedir
和进行增量备份xtrabackup --incremental-lsn
。如果没有找到有效的 LSN(没有具有该 UUID 的成功记录),xtrabackup将返回错误。此选项与xtrabackup --incremental
选项一起使用。
--增量-lsn=LSN
创建增量备份时,您可以指定日志序列号 ( LSN
) 而不是指定 xtrabackup --incremental-basedir
. 对于在 5.1 及更高版本中创建的数据库,将 LSN 指定为单个 64 位整数。注意:如果指定了错误的 LSN 值(Percona XtraBackup无法检测到的用户错误),备份将无法使用。当心!
--innodb-log-arch-dir=目录
此选项用于指定包含归档日志的目录。它只能与xtrabackup --prepare
选项一起使用。
--innodb-杂项
通常从 my.cnf
配置文件中读取大量 InnoDB 选项,以便xtrabackup以与当前服务器相同的配置启动其嵌入式 InnoDB。您通常不需要明确指定这些。这些选项具有与 InnoDB 或 XtraDB 中相同的行为。它们如下:
--innodb-adaptive-hash-index
--innodb-additional-mem-pool-size
--innodb-autoextend-increment
--innodb-buffer-pool-size
--innodb-checksums
--innodb-data-file-path
--innodb-data-home-dir
--innodb-doublewrite-file
--innodb-doublewrite
--innodb-extra-undoslots
--innodb-fast-checksum
--innodb-file-io-threads
--innodb-file-per-table
--innodb-flush-log-at-trx-commit
--innodb-flush-method
--innodb-force-recovery
--innodb-io-capacity
--innodb-lock-wait-timeout
--innodb-log-buffer-size
--innodb-log-files-in-group
--innodb-log-file-size
--innodb-log-group-home-dir
--innodb-max-dirty-pages-pct
--innodb-open-files
--innodb-page-size
--innodb-read-io-threads
--innodb-write-io-threads
--innodb-撤消目录=名称
撤消表空间的目录位置。路径是绝对的。
--innodb-undo-tablespace=
要使用的撤消表空间数。
--keyring-file-data=文件名
密钥环文件的路径。将此选项与 xtrabackup --xtrabackup-plugin-dir
.
--kill-long-queries-timeout=
此选项指定 xtrabackup 在启动 FLUSH TABLES WITH READ LOCK 和终止那些阻止它的查询之间等待的秒数。默认值为0
(零)秒,这意味着 xtrabackup 不会尝试终止任何查询。
--kill-long-query-type=select|all
此选项指定应终止哪些类型的查询以解除对全局锁的阻塞。默认值为select
。
--lock-ddl
LOCK TABLES FOR BACKUP
如果服务器在备份开始时支持阻止所有 DDL 操作,则会发出问题。
--lock-ddl-per-table
在 xtrabackup 开始复制之前为每个表锁定 DDL,直到备份完成。
--lock-ddl-超时
如果LOCK TABLES FOR BACKUP
在给定的超时时间内没有返回,则中止备份。
--log-bin[=名称]
日志序列的基本名称。
--log-copy-interval=
此选项指定日志复制线程检查之间的时间间隔,以毫秒为单位(默认为 1 秒)。
--登录路径=
从登录文件中读取此路径。
--后退
将先前制作的备份中的所有文件从备份目录移至其原始位置。由于此选项会删除备份文件,因此必须谨慎使用。
–无备份锁
此选项控制是否使用备份锁而不是FLUSH TABLES WITH READ LOCK
在备份阶段。服务器上必须支持备份锁才能使选项生效。
默认情况下启用此选项。使用 禁用该选项--no-backup-locks
。
--无默认值
不要从任何选项文件中读取默认选项。必须作为命令行上的第一个选项给出。
--无锁
此选项自动使用备份锁,并禁用表锁,作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。
仅当所有表都是 InnoDB 并且您不关心备份的二进制日志位置时才使用此选项。
如果将执行任何 DDL 语句或正在更新任何非 InnoDB 表(这包括 mysql 数据库中的 MyISAM 表),请不要使用此选项。在这些情况下使用此选项可能会导致备份不一致。
如果您的备份未能获取锁并且您计划使用此选项,则失败可能是由阻止锁成功的传入复制事件引起的。尝试--safe-slave-backup
暂时停止复制从属线程。
使用xtrabackup-binlog-info
时不会创建 ,--no-lock
因为SHOW MASTER STATUS
可能不一致。在某些情况下,xtrabackup_binlog_pos_innodb
可用于获取一致的二进制日志坐标,如使用二进制日志中所述。
--无版本检查
此选项禁用版本检查。如果您不通过此选项,则当 xtrabackup 在该--backup
模式下运行时,会隐式启用自动版本检查。要禁用版本检查,请--no-version-check
在调用 xtrabackup 时显式传递该选项。
启用自动版本检查后,xtrabackup 会在创建服务器连接后在备份阶段对服务器执行版本检查。xtrabackup 将以下信息发送到服务器:
- MySQL 风格和版本
- 操作系统名称
- Percona 工具包版本
- Perl 版本
每条信息都有一个唯一标识符,这是一个 MD5 哈希值,Percona Toolkit 使用它来获取有关其使用方式的统计信息。这个值是一个随机的 UUID;不会收集或存储任何客户信息。
--打开文件限制=
使用 setrlimit() 保留的最大文件描述符数。
--平行=
此选项指定创建备份时用于同时复制多个数据文件的线程数。默认值为 1(即,无并发传输)。在Percona XtraBackup 2.3.10 和更新版本中,此选项可以与xtrabackup --copy-back
并行复制用户数据文件的选项一起使用(重做日志和系统表空间在主线程中复制)。
--password=密码
此选项指定连接到数据库时要使用的密码。它接受一个字符串参数。详情请参阅mysql --help
。
-准备
对使用 创建的备份xtrabackup
执行恢复 xtrabackup --backup
,以便它可以使用。请参阅 准备备份。
--打印默认值
打印程序参数列表并退出。必须作为命令行上的第一个选项给出。
--打印参数
打印xtrabackup
出将数据文件复制回其原始位置以恢复它们的参数。请参阅 使用 xtrabackup 编写备份脚本。
--读取缓冲区大小[=#]
设置读取缓冲区大小。给定值按比例放大到页面大小。默认值为 10MB。
使用此变量可将 xbcloud/xbstream 块大小从默认值 10MB 增加。
注意:当您使用加密时,要调整 xbcloud/xbstream 块大小,请同时调整--encrypt-chunk-size
和--read-buffer-size
变量。
$ xtrabackup ... --read-buffer-size=1G | xbcloud put ...
--重建索引
应用日志后重建 InnoDB 表中的二级索引。仅与 –prepare 一起使用。
--重建线程=
此选项定义在紧凑备份中重建索引的线程数。仅与--prepare
和一起使用--rebuild-indexes
。
--重做日志版本=
备份的重做日志版本。仅与 一起使用--prepare
。
--reencrypt-for-server-id=
使用此选项启动具有与获取加密备份的服务器不同的 server_id 的服务器实例,例如复制副本或 Galera 节点。使用此选项时,xtrabackup 将作为准备步骤,根据新的 server_id 生成具有 ID 的新主密钥,将其存储到密钥环文件中,并重新加密表空间标头内的表空间密钥。该选项应通过--prepare
(最后一步)。
--删除-原始
在Percona XtraBackup 2.4.6 中实现,指定此选项时将删除.qp
,.xbcrypt
和.qp.xbcrypt
解密和解压缩后的文件。
--rsync
使用该rsync
实用程序优化本地文件传输。
指定此选项时,xtrabackup 用于rsync
复制所有非 InnoDB 文件,而不是为每个文件生成单独的复制命令。对于具有大量数据库或表的服务器,此选项更快。
此选项不能与 一起使用--stream
。
--安全从属备份
指定后,xtrabackup 将在运行之前停止副本 SQL 线程FLUSH TABLES WITH READ LOCK
并等待启动备份,直到 Slave_open_temp_tables
inSHOW STATUS
为零。如果没有打开的临时表,就会进行备份;否则 SQL 线程将被启动和停止,直到没有打开的临时表。Slave_open_temp_tables
如果在 xtrabackup –safe-slave-backup-timeout 秒后没有变为零,备份将失败。备份完成后,副本 SQL 线程将重新启动。此选项用于处理复制临时表 ,对于基于行的复制不是必需的。
--safe-slave-backup-timeout=SECONDS
xtrabackup --safe-slave-backup
应该等待 多少秒Slave_open_temp_tables
变为零。默认值为 300 秒。
--安全认证
如果客户端使用旧的(4.1.1 之前的)协议,则拒绝客户端连接到服务器。(默认启用;使用 –skip-secure-auth 禁用。)
--server-id=
正在备份的服务器实例。
--server-public-key-path=name
PEM 格式的服务器公共 RSA 密钥的文件路径。
--skip-tables-兼容性检查
此选项禁用引擎兼容性警告。
也可以看看
--tables-compatibility-check
–奴隶信息
此选项在备份复制副本服务器时很有用。它打印源服务器的二进制日志位置。xtrabackup_slave_info
它还将二进制日志坐标作为CHANGE MASTER
命令写入文件。可以通过在此备份上启动副本服务器并CHANGE MASTER
使用保存在 xtrabackup_slave_info 文件中的二进制日志位置发出命令来设置此源的新副本。
–ssl
启用安全连接。更多信息可以在–ssl MySQL 服务器文档中找到。
–ssl-ca
文件的路径,其中包含受信任的 SSL CA 的列表。更多信息可以在–ssl-ca MySQL 服务器文档中找到。
–ssl-capath
包含 PEM 格式的受信任 SSL CA 证书的目录路径。更多信息可以在–ssl-capath MySQL 服务器文档中找到。
–ssl 证书
包含 PEM 格式的 X509 证书的文件的路径。更多信息可以在–ssl-cert MySQL 服务器文档中找到。
–ssl密码
用于连接加密的允许密码列表。更多信息可以在–ssl-cipher MySQL 服务器文档中找到。
--ssl-crl
包含证书吊销列表的文件的路径。更多信息可以在–ssl-crl MySQL 服务器文档中找到。
--ssl-crlpath
包含证书吊销列表文件的目录的路径。更多信息可以在–ssl-crlpath MySQL 服务器文档中找到。
–ssl 密钥
包含 PEM 格式的 X509 密钥的文件的路径。更多信息可以在–ssl-key MySQL 服务器文档中找到。
–ssl 模式
连接到服务器的安全状态。更多信息可以在 –ssl-mode MySQL 服务器文档中找到。
–ssl-验证服务器证书
根据连接到服务器时使用的主机名验证服务器证书公用名值。更多信息可以在 –ssl-verify-server-cert MySQL 服务器文档中找到。
–统计数据
使 xtrabackup 扫描指定的数据文件并打印出索引统计信息。
–流=名称
将所有备份文件以指定格式流式传输到标准输出。当前支持的格式是xbstream
和tar
。
--tables=名称
一个正则表达式,与 databasename.tablename
格式的完整表名匹配。如果名称匹配,则备份该表。请参阅部分备份。
--tables-兼容性检查
此选项启用引擎兼容性警告。
默认值为ON
。用于--skip-tables-compatibility-check
禁用。
--tables-exclude=name
通过正则表达式过滤表名。操作方式与 相同xtrabackup --tables
,但从备份中排除匹配的名称。请注意,此选项的优先级高于 xtrabackup --tables
。
--tables-file=名称
每行包含一个表名的文件,采用 databasename.tablename 格式。备份将仅限于指定的表。请参阅 使用 xtrabackup 编写备份脚本。
--target-dir=目录
此选项指定备份的目标目录。如果目录不存在,xtrabackup
则创建它。如果目录确实存在并且为空,xtrabackup
则将成功。 xtrabackup
不会覆盖现有文件;但是它将因操作系统错误 17 失败,file exists
.
如果此选项是相对路径,则将其解释为相对于执行 xtrabackup 的当前工作目录。
为了执行备份,您需要 在文件系统级别为您提供为 的值的目录具有READ
、WRITE
和权限。EXECUTE--target-dir
--油门=
此选项限制每秒复制的块数。块大小为 10 MB。
要将带宽限制为10 MB/s,请将选项设置为1 :。 --throttle=1
–tls-版本=名称
要使用的 TLS 版本。允许的值如下:
- TLSv1
- TLSv1.1
- TLSv1.2
–tmpdir=名称
除了在使用时打印出正确的 tmpdir 参数外,此选项目前不用于任何xtrabackup --print-param
用途。
--to-archived-lsn=LSN
此选项用于指定在准备备份时应应用日志的 LSN。它只能与 xtrabackup --prepare
选项一起使用。
--转换键
此选项用于启用处理备份而不访问密钥环保险库服务器。在这种情况下,xtrabackup 从指定的密码短语派生 AES 加密密钥,并使用它来加密正在备份的表空间的表空间密钥。
如果--transition-key <xtrabackup –transition-key>
没有任何值,xtrabackup 会要求它。应该为xtrabackup --prepare
命令指定相同的密码。
--使用内存=
此选项会影响为准备备份 xtrabackup --prepare
或使用 分析统计信息 分配的内存量xtrabackup --stats
。其目的类似于innodb_buffer_pool_size
. 它与 Oracle 的 InnoDB 热备份工具中类似名称的选项不同。默认值是 100MB,如果你有足够的可用内存,1GB 到 2GB 是一个不错的推荐值。提供单位时支持倍数(例如 1MB、1M、1GB、1G)。
--user=用户名
此选项指定连接到服务器时使用的 MySQL 用户名,如果那不是当前用户。该选项接受一个字符串参数。有关详细信息,请参阅 mysql –help。
-版本
此选项打印xtrabackup版本并退出。
–xtrabackup-plugin-dir=DIRNAME
包含keyring
插件的目录的绝对路径。
也可以看看
Percona Server for MySQL 文档:带有静态数据加密的 keyring_vault 插件 https://www.percona.com/doc/percona-server/5.7/security/data-at-rest-encryption.html MySQL 文档:使用 keyring_file 文件-基于插件 https://dev.mysql.com/doc/refman/5.7/en/keyring-file-plugin.html
innobackupex 选项参考
此页面记录了innobackupex
.
选项
--应用日志
BACKUP-DIR
通过应用 xtrabackup_logfile
位于同一目录中的事务日志文件来准备备份。此外,创建新的事务日志。InnoDB 配置是从 备份时由innobackupexbackup-my.cnf
创建的文件中读取的。默认情况下使用 InnoDB 配置 ,如果指定,则使用 from 。在这种情况下,InnoDB 配置是指影响数据格式的服务器变量,即,等。与位置相关的变量,例如或总是被 忽略,因此准备备份总是使用备份目录中的数据文件,而不是任何外部文件。innobackupex --apply-logbackup-my.cnf--defaults-fileinnodb_page_sizeinnodb_log_block_sizeinnodb_log_group_home_dirinnodb_data_file_path--apply-log
--备份锁
此选项控制是否应使用备份锁而不是FLUSH TABLES WITH READ LOCK
在备份阶段使用。当服务器不支持备份锁时,该选项无效。此选项默认启用,使用 禁用--no-backup-locks
。
–无备份锁
显式禁用–-backup-locks
默认启用的选项。
--关闭文件
不要让文件保持打开状态。此选项直接传递给 xtrabackup。当 xtrabackup 打开表空间时,它通常不会关闭其文件句柄以正确处理 DDL 操作。但是,如果表空间的数量确实很大并且无法满足任何限制,则可以选择在不再访问文件句柄时关闭它们。Percona XtraBackup 可以在启用此选项的情况下生成不一致的备份。使用风险自负。
-压缩
此选项指示 xtrabackup 压缩 InnoDB 数据文件的备份副本。它直接传递给 xtrabackup 子进程。有关详细信息,请参阅 xtrabackup文档。
--压缩线程=
此选项指定将用于并行压缩的工作线程数。它直接传递给 xtrabackup 子进程。有关详细信息,请参阅 xtrabackup文档。
--压缩块大小=
此选项指定每个压缩线程的内部工作缓冲区的大小,以字节为单位。它直接传递给 xtrabackup 子进程。默认值为 64K。有关详细信息,请参阅 xtrabackup
文档。
– 复制回
将先前制作的备份中的所有文件从备份目录复制到其原始位置。除非指定选项,否则Percona XtraBackup innobackupex --copy-back
选项不会复制现有文件 innobackupex --force-non-empty-directories
。
--数据库=列表
此选项指定innobackupex应备份的数据库列表。该选项接受字符串参数或包含要备份的数据库列表的文件路径。该列表的格式为“databasename1[.table_name1] databasename2[.table_name2] ...”。如果未指定此选项, 则将备份包含MyISAM和InnoDB表的所有数据库。请确保 --databases 包含所有InnoDB数据库和表,以便同时备份所有 innodb.frm 文件。如果列表很长,可以在文件中指定,并且可以指定文件的完整路径而不是列表。(请参阅选项 –tables-file。)
--解压
innobackupex --compress
解压缩之前使用该选项制作的备份中所有扩展名为 .qp 的文件。该innobackupex --parallel
选项将允许同时解密和/或解压缩多个文件。为了解压缩,必须安装 qpress 实用程序并且可以在路径中访问。Percona XtraBackup不会自动删除压缩文件。为了清理备份目录,用户应该\*.qp
手动删除文件。
--decrypt=加密算法
解密之前使用 –encrypt 选项制作的备份中所有扩展名为 .xbcrypt 的文件。该innobackupex --parallel
选项将允许同时解密和/或解压缩多个文件。
--defaults-file=[MY.CNF]
此选项接受一个字符串参数,该参数指定从哪个文件读取默认 MySQL 选项。必须作为命令行上的第一个选项给出。
--defaults-extra-file=[MY.CNF]
此选项指定从标准默认文件之前读取默认MySQL选项的额外文件。必须作为命令行上的第一个选项给出。
--defaults-group=组名
此选项接受一个字符串参数,该参数指定应从配置文件中读取的组。如果您使用 mysqld_multi,则需要这样做。这也可用于指示除 mysqld 和 xtrabackup 之外的组。
--encrypt=ENCRYPTION_ALGORITHM
此选项指示 xtrabackup 使用 ENCRYPTION_ALGORITHM 中指定的算法加密 InnoDB 数据文件的备份副本。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅xtrabackup
文档。
目前,支持以下算法AES128
: AES192
和AES256
。
--encrypt-key=ENCRYPTION_KEY
此选项指示 xtrabackup 在使用 –encrypt 选项时使用给定的适当长度的加密密钥作为 ENCRYPTION_KEY。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅xtrabackup
文档。
不建议在对机器进行不受控制的访问的情况下使用此选项作为命令行,因此可以将密钥视为进程信息的一部分。
--encrypt-key-file=ENCRYPTION_KEY_FILE
此选项指示 xtrabackup 在使用 –encrypt 选项时使用存储在给定 ENCRYPTION_KEY_FILE 中的加密密钥。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅xtrabackup
文档。
该文件必须是一个简单的二进制(或文本)文件,其中包含要使用的密钥。
--加密线程=
此选项指定将用于并行加密的工作线程数。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅xtrabackup
文档。
--加密块大小=
此选项指定每个加密线程的内部工作缓冲区的大小,以字节为单位。它直接传递给 xtrabackup 子进程。有关更多详细信息,请参阅xtrabackup
文档。
-出口
此选项直接传递给xtrabackup --export
选项。它可以导出单个表以导入另一台服务器。有关详细信息,请参阅 xtrabackup文档。
--extra-lsndir=目录
此选项接受一个字符串参数,该参数指定要在其中保存文件的额外副本的xtrabackup_checkpoints
目录。它直接传递给xtrabackup的innobackupex --extra-lsndir
选项。有关详细信息,请参阅 xtrabackup 文档。
--force-非空目录
指定时,它使innobackupex --copy-back
选项或 innobackupex --move-back
选项将文件传输到非空目录。不会覆盖现有文件。如果 –copy-back 或 –move-back 必须从目标目录中已存在的备份目录中复制文件,它仍然会失败并出现错误。
–galera信息
此选项创建xtrabackup_galera_info
包含备份时本地节点状态的文件。执行 Percona-XtraDB-Cluster 备份时应使用选项。使用备份锁创建备份时无效。
-帮助
此选项显示帮助屏幕并退出。
--历史=名称
此选项启用 PERCONA_SCHEMA.xtrabackup_history
表中备份历史记录的跟踪。可以指定一个可选的历史系列名称,该名称将与当前备份的历史记录一起放置。
--主机=主机
此选项接受一个字符串参数,该参数指定使用 TCP/IP 连接到数据库服务器时要使用的主机。它被传递给 mysql 子进程而无需更改。详情请参阅mysql --help
。
–ibbackup=IBBACKUP-二进制
此选项指定应使用哪个xtrabackup二进制文件。该选项接受一个字符串参数。IBBACKUP-BINARY 应该是用于运行 Percona XtraBackup的命令。如果xtrabackup二进制文件不在您的搜索路径或工作目录中,该选项会很有用。如果未指定此选项,innobackupex 将尝试确定要自动使用的二进制文件。
--include=REGEXP
此选项是一个正则表达式,以 databasename.tablename
格式与表名匹配。它直接传递给 xtrabackup 的 xtrabackup --tables
选项。有关详细信息,请参阅 xtrabackup 文档。
-增加的
此选项告诉xtrabackup创建增量备份,而不是完整备份。它被传递给xtrabackup子进程。当指定此选项时,也可以给出innobackupex --incremental-lsn
或 给出。innobackupex --incremental-basedir
如果两个选项都没有给出,则选项默认innobackupex --incremental-basedir
传递给 xtrabackup
,设置为备份基目录中的第一个时间戳备份目录。
--incremental-basedir=目录
此选项接受一个字符串参数,该参数指定包含完整备份的目录,该目录是增量备份的基本数据集。它与innobackupex --incremental
选项一起使用。
--incremental-dir=目录
此选项接受一个字符串参数,该参数指定增量备份将与完整备份组合以进行新的完整备份的目录。它与innobackupex --incremental
选项一起使用。
--incremental-history-name=NAME
此选项指定存储在 PERCONA_SCHEMA.xtrabackup_history历史记录中的备份系列的名称,以作为增量备份的基础。Percona Xtrabackup 将搜索历史表,查找系列中最近(最高的 innodb_to_lsn)成功备份,并将 to_lsn 值用作增量备份的起始 lsn。 这将与innobackupex --incremental-history-uuid
和互斥 。如果找不到有效的lsn(没有该名称的系列,没有该名称的成功备份)xtrabackup 将返回错误。它与 选项一起使用。innobackupex --incremental-basedirinnobackupex --incremental-lsninnobackupex --incremental
--incremental-history-uuid=UUID
此选项指定存储在 PERCONA_SCHEMA.xtrabackup_history中的特定历史记录的 UUID,以作为增量备份的基础。innobackupex --incremental-history-name
,innobackupex --incremental-basedir\
和 innobackupex --incremental-lsn
. 如果找不到有效的 lsn(没有该 uuid 的成功记录),xtrabackup 将返回错误。它与innobackupex --incremental
选项一起使用。
--增量-lsn=LSN
此选项接受一个字符串参数,该参数指定LSN
用于增量备份的日志序列号 ( )。它与 innobackupex --incremental
选项一起使用。使用它而不是指定 innobackupex --incremental-basedir
. 对于MySQL和 Percona Server 5.0 系列版本创建的数据库,将 指定为两个 32 位整数,采用 high:low 格式。对于在 5.1 及更高版本中创建的数据库,将 LSN 指定为单个 64 位整数。
--kill-long-queries-timeout=SECONDS
此选项指定 innobackupex 在启动FLUSH TABLES WITH READ LOCK
和终止阻止它的查询之间等待的秒数。默认值为 0 秒,这意味着 innobackupex 不会尝试终止任何查询。为了使用这个选项,xtrabackup 用户应该拥有 PROCESS
和SUPER
权限。如果支持(Percona Server 5.6+)xtrabackup 将自动使用备份锁 作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。
--kill-long-query-type=all|选择
此选项指定应终止哪些类型的查询以解除对全局锁的阻塞。默认为“全部”。
--ftwrl-等待超时=秒
此选项以秒为单位指定 innobackupexFLUSH TABLES WITH READ LOCK
在运行之前应等待会阻塞的查询的时间。如果超时后仍有此类查询,则 innobackupex 会以错误终止。默认值为 0,在这种情况下,innobackupex 不会等待查询完成并FLUSH TABLES WITH READ LOCK
立即启动。如果支持(Percona Server 5.6+)xtrabackup 将自动使用备份锁 作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。
--ftwrl-wait-threshold=SECONDS
此选项指定查询运行时间阈值,innobackupex 使用该阈值来检测具有非零值的长时间运行的查询 innobackupex –ftwrl-wait-timeout
。FLUSH TABLES WITH READ LOCK
在存在此类长时间运行的查询之前不会启动。如果 –ftwrl-wait-timeout 为 0,则此选项无效。默认值为 60 秒。如果支持(Percona Server 5.6+)xtrabackup 将自动使用备份锁 作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。
–ftwrl-wait-query-type=全部|更新
此选项指定在 innobackupex 发出全局锁之前允许完成哪些类型的查询。默认为全部。
--log-copy-interval=
此选项指定日志复制线程完成的检查之间的时间间隔(以毫秒为单位)。
--后退
将先前制作的备份中的所有文件从备份目录移至其原始位置。由于此选项会删除备份文件,因此必须谨慎使用。
--无锁
使用此选项来禁用表锁定FLUSH TABLES WITH READ LOCK
。仅当您的所有表都是 InnoDB 并且您不关心 备份的二进制日志位置时才使用它。DDL
如果正在执行任何语句或在非 InnoDB 表上发生任何更新(这包括 mysql数据库中的系统 MyISAM 表),则不应使用此选项,否则可能导致备份不一致。如果支持(Percona Server 5.6+)xtrabackup 将自动使用备份锁 作为FLUSH TABLES WITH READ LOCK
复制非 InnoDB 数据的轻量级替代方案,以避免阻塞修改 InnoDB 表的 DML 查询。如果您正在考虑使用innobackupex --no-lock because
您的备份无法获取锁,这可能是因为传入的复制事件阻止了锁成功。请尝试使用 innobackupex --safe-slave-backup
暂时停止复制副本线程,这可能有助于备份成功,然后您无需使用此选项。 xtrabackup_binlog_info
使用 –no-lock 选项时不会创建(因为SHOW MASTER STATUS
可能会不一致),但在某些条件下 xtrabackup_binlog_pos_innodb
可以用来获取一致的二进制日志坐标,如使用二进制日志中所述。
--无时间戳
BACKUP-ROOT-DIR
此选项可防止在命令行上创建给定的时间戳子目录 。BACKUP-ROOT-DIR
指定后,将改为执行备份。
--无版本检查
此选项禁用版本检查。如果不通过此选项,则在模式下xtrabackup
运行时会隐式启用自动版本检查。--backup
要禁用版本检查,请--no-version-check
在调用xtrabackup
. 当启用自动版本检查时,|program| 创建服务器连接后,在备份阶段对服务器执行版本检查。
xtrabackup
向服务器发送以下信息:
- MySQL 风格和版本
- 操作系统名称
- Percona 工具包版本
- Perl 版本
每条信息都有一个唯一标识符,这是一个 MD5 哈希值,Percona Toolkit 使用它来获取有关其使用方式的统计信息。这个值是一个随机的 UUID;不会收集或存储任何客户信息。
--parallel=NUMBER-OF-THREADS
此选项接受一个整数参数,该参数指定xtrabackup
子进程用于同时备份文件的线程数。请注意,此选项适用于文件级别,也就是说,如果您有多个 .ibd 文件,它们将被并行复制。如果您的表一起存储在单个表空间文件中,则不会产生任何影响。此选项将允许同时解密和/或解压缩多个文件。为了解压缩,必须安装 qpress 实用程序并且可以在路径中访问。此过程将删除原始压缩/加密文件并将结果保留在同一位置。它直接传递给 xtrabackup 的xtrabackup --parallel
选项。有关详细信息,请参阅xtrabackup
文档
--password=密码
此选项接受一个字符串参数,指定连接到数据库时要使用的密码。它被传递给mysql
子进程而无需更改。详情请参阅mysql --help
。
–端口=端口
此选项接受一个字符串参数,该参数指定使用 TCP/IP 连接到数据库服务器时要使用的端口。它被传递给 mysql
子进程。它被传递给mysql
子进程而无需更改。详情请参阅mysql --help
。
--重建索引
此选项仅在与该选项一起使用时才有效,--apply-log <innobackupex --apply-log>
并直接传递给 xtrabackup。使用时,使 xtrabackup 在应用日志后重建所有二级索引。此选项通常用于准备紧凑备份。有关更多信息,请参阅xtrabackup
文档。
--rebuild-threads=NUMBER-OF-THREADS
innobackupex --apply-log
此选项仅在与and选项一起使用时才有效,innobackupex --rebuild-indexes
并直接传递给 xtrabackup。使用时,xtrabackup 在重建索引时以指定数量的线程并行处理表空间。有关更多信息,请参阅 xtrabackup
文档。
--redo-only
在准备基本完整备份以及合并除最后一个之外的所有增量时,应使用此选项。它直接传递给 xtrabackup 的xtrabackup --apply-log-only
选项。这迫使 xtrabackup
跳过“回滚”阶段并仅执行“重做”。如果备份稍后将应用增量更改,则这是必要的。有关详细信息,请参阅xtrabackup 文档。
--rsync
使用该rsync
实用程序优化本地文件传输。指定此选项时,innobackupex
用于rsync
复制所有非 InnoDB 文件,而不是cp
为每个文件生成单独的文件,这对于具有大量数据库或表的服务器来说可能更快。此选项不能与 一起使用innobackupex --stream
。
--安全从属备份
指定后,innobackupex 将在运行之前停止副本 SQL 线程FLUSH TABLES WITH READ LOCK
并等待开始备份,直到 Slave_open_temp_tables
inSHOW STATUS
为零。如果没有打开的临时表,则进行备份,否则将启动和停止 SQL 线程,直到没有打开的临时表。如果几秒Slave_open_temp_tables
后没有变为零, 备份将失败。innobackupex --safe-slave-backup-timeout
备份完成后,副本 SQL 线程将重新启动。
--safe-slave-backup-timeout=SECONDS
innobackupex --safe-slave-backup
应该等待 多少秒Slave_open_temp_tables
变为零。默认为 300 秒。
–奴隶信息
此选项在备份复制副本服务器时很有用。它打印源服务器的二进制日志位置和名称。它还将此信息xtrabackup_slave_info
作为CHANGE MASTER
命令写入文件。可以通过在此备份上启动副本服务器并CHANGE MASTER
使用保存在xtrabackup_slave_info
文件中的二进制日志位置发出命令来设置此源的新副本。
-插座
此选项接受一个字符串参数,该参数指定使用 UNIX 域套接字连接到本地数据库服务器时要使用的套接字。它被传递给 mysql 子进程而无需更改。详情请参阅mysql --help
。
–流=流名称
此选项接受一个字符串参数,该参数指定执行流式备份的格式。备份将以STDOUT
指定的格式完成。目前,支持的格式是tar
和xbstream
。使用 xbstream,它在Percona XtraBackup 发行版中可用。如果在此选项后指定路径,它将被解释为tmpdir
--tables-file=文件
此选项接受一个字符串参数,该参数指定文件中的名称列表,格式为database.table
,每行一个。该选项直接传递给xtrabackup
的innobackupex --tables-file
选项。
--油门=
此选项限制每秒复制的块数。块大小为 10 MB。要将带宽限制为10 MB/s,请将选项设置为1 :。 --throttle=1
也可以看看
有关如何限制备份的更多信息限制备份。
--tmpdir=目录
此选项接受一个字符串参数,该参数指定将存储临时文件的位置。指定时可以使用innobackupex --stream
。对于这些选项,事务日志将首先存储到临时文件中,然后再流式传输或复制到远程主机。此选项指定将存储该临时文件的位置。如果未指定该选项,则默认使用tmpdir
从服务器配置中读取的值。innobackupex 将 my.cnf 中指定的 tmpdir 值作为--target-dir
选项传递给 xtrabackup 二进制文件。[mysqld] 和 [xtrabackup] 组都是从 my.cnf 中读取的。如果两者中都有 tmpdir,则使用的值取决于 my.cnf 中这些组的顺序。
--使用内存=
xtrabackup
此选项接受一个字符串参数,该参数指定在准备备份时用于崩溃恢复的内存量(以字节为单位) 。提供单位时支持倍数(例如 1MB、1M、1GB、1G)。它仅与选项一起使用innobackupex --apply-log
。它直接传递给 xtrabackup 的xtrabackup --use-memory
选项。有关详细信息,请参阅 xtrabackup文档。
--用户=用户
此选项接受一个字符串参数,该参数指定登录用户(即 连接到服务器时使用的MySQL用户名),如果该用户不是当前用户。它被传递给 mysql 子进程而无需更改。详情请参阅mysql --help
。
-版本
此选项显示innobackupex版本和版权声明,然后退出。
xbcloud 二进制文件
xbcloud的目的是从/向云下载和上传全部或部分 xbstream 存档。xbcloud不会覆盖同名的备份。xbcloud通过管道从 xbstream 接受输入,因此可以使用xtrabackup将其作为管道调用以直接流式传输到云,而无需本地存储。
笔记
在 Bash shell 中,该$?
参数返回最后一个二进制文件的退出代码。如果使用管道,则${PIPESTATUS[x]}
数组参数返回管道字符串中每个二进制文件的退出代码。
$ xtrabackup --backup --stream=xbstream --target-dir=/storage/backups/ | xbcloud put [options] full_backup
> true | false
> echo $?
> 1
# with PIPESTATUS
> true | false
> echo ${PIPESTATUS[0]} ${PIPESTATUS[1]}
> 0 1
xbcloud二进制文件将每个块存储为具有 name 的单独对象 ,backup_name/database/table.ibd.NNNNNNNNNNNNNNNNNNNN
其中NNN...
是文件中块的 0 填充序列号。xtrabackup和 xbstream生成的块大小 更改为 10MB。
笔记
用于--read-buffer-size
调整块大小。
如果您使用加密,请同时指定--read-buffer-size
和--encrypt-chunk-size
选项来调整块大小。
xbcloud具有三个基本操作:put、get和delete。通过这些操作,可以创建、存储、检索、恢复和删除备份。xbcloud操作清楚地映射到 AWS S3 API 中的类似操作。
版本特定信息
- 2.4.25 - 增加了对微软 Azure 云存储的支持
- 2.4.21 - 添加了 s3-storage-class 和 google-storage-class
- 2.4.14 - 增加了对Amazon S3、MinIO和Google Cloud Storage存储类型的支持。
- 2.3.1-beta1 - 实现了将xbcloud参数存储在 .cnf 文件中的功能
- 2.3.1-beta1 - 实现了对 Swift不同身份验证选项的支持
- 2.3.1-beta1 - 支持部分下载云备份
- 2.3.1-beta1 -
xbcloud --swift-url
选项已重命名为xbcloud --swift-auth-url
- 2.3.0-alpha1 - 初始实现
支持的云存储类型
在Percona XtraBackup 2.4.14之前,Swift 是在云存储中存储备份的唯一选择。目前,xbcloud 二进制文件支持Amazon S3、Azure、MinIO和Google Cloud Storage。还支持与 Amazon S3 兼容的云存储类型,例如 Wasabi 和 Digital Ocean Spaces。
也可以看看
用法
$ xtrabackup --backup --stream
=xbstream --target-dir
=/tmp
|xbcloud
\
put
[options
]<name>
使用 Swift 创建完整备份
以下示例显示了如何进行完整备份并将其上传到 Swift。
$ xtrabackup --backup --stream
=xbstream --extra-lsndir
=/tmp --target-dir
=/tmp
|\
xbcloud put --storage
=swift
\
--swift-container
=test\
--swift-user
=test:tester
\
--swift-auth-url
=http://192.168.8.80:8080/
\
--swift-key
=testing
\
--parallel
=10\
full_backup
使用Amazon S3创建完整备份
$ xtrabackup --backup --stream
=xbstream --extra-lsndir
=/tmp --target-dir
=/tmp
|\
xbcloud put --storage
=s3
\
--s3-endpoint
='s3.amazonaws.com'\
--s3-access-key
='YOUR-ACCESSKEYID'\
--s3-secret-key
='YOUR-SECRETACCESSKEY'\
--s3-bucket
='mysql_backups'
--parallel
=10\
$(date -I
)-full_backup
使用Amazon S3时可以使用以下选项:
选项 |
细节 |
–s3-访问密钥 |
用于提供 AWS 访问密钥 ID |
–s3-密钥 |
用于提供 AWS 秘密访问密钥 |
–s3-bucket |
使用提供 AWS 存储桶名称 |
–s3-区域 |
用于指定 AWS 区域。默认值为us-east-1 |
–s3-api-version = <自动|2|4> |
选择签名算法。默认值为自动。在这种情况下,xbcloud将进行探测。 |
–s3-bucket-lookup = <AUTO|PATH|DNS> |
指定是使用bucket.endpoint.com还是endpoint.com/bucket*样式请求。默认值为自动。在这种情况下,xbcloud将进行探测。 |
–s3-storage-class=<名称> |
指定S3 存储类。名称选项如下: |
使用 MinIO 创建完整备份
$ xtrabackup --backup --stream
=xbstream --extra-lsndir
=/tmp --target-dir
=/tmp
|\
xbcloud put --storage
=s3
\
--s3-endpoint
='play.minio.io:9000'\
--s3-access-key
='YOUR-ACCESSKEYID'\
--s3-secret-key
='YOUR-SECRETACCESSKEY'\
--s3-bucket
='mysql_backups'
--parallel
=10\
$(date -I
)-full_backup
使用 Google Cloud Storage 创建完整备份
使用互操作模式实现对 Google Cloud Storage 的支持。此模式专门设计用于与兼容Amazon S3的云服务进行交互。
也可以看看
云存储互操作性 https://cloud.google.com/storage/docs/interoperability
$ xtrabackup --backup --stream
=xbstream --extra-lsndir
=/tmp --target-dir
=/tmp
|\
xbcloud put --storage
=
--google-endpoint
=`storage.googleapis.com
`\
--google-access-key
='YOUR-ACCESSKEYID'\
--google-secret-key
='YOUR-SECRETACCESSKEY'\
--google-bucket
='mysql_backups'
--parallel
=10\
$(date -I
)-full_backup
使用 Google Cloud Storage 时可以使用以下选项:
- --google-access-key = <访问密钥 ID>
- --google-secret-key = <秘密访问密钥>
- --google-bucket = <存储桶名称>
- --google-存储类=名称
笔记
Google 存储类名称选项如下:
- 标准
- 近线
- 冷线
- 档案
另请参阅:Google 存储类
提供参数
每种存储类型都有强制参数,您可以在命令行、配置文件和环境变量中提供这些参数。
配置文件
其值不经常更改的参数可以存储在 自定义配置文件中my.cnf
或自定义配置文件中。以下示例是该[xbcloud]
组下的配置选项模板:
[xbcloud]
storage=s3
s3-endpoint=http://localhost:9000/
s3-access-key=minio
s3-secret-key=minio123
s3-bucket=backupsx
s3-bucket-lookup=path
s3-api-version=4
笔记
如果您在命令行和配置文件中显式使用参数,xbcloud将使用命令行中提供的值。
环境变量
识别以下环境变量。xbcloud自动将它们映射到适用于所选存储的相应参数。
- AWS_ACCESS_KEY_ID(或 ACCESS_KEY_ID)
- AWS_SECRET_ACCESS_KEY(或 SECRET_ACCESS_KEY)
- AWS_DEFAULT_REGION(或 DEFAULT_REGION)
- AWS_ENDPOINT(或 ENDPOINT)
- AWS_CA_BUNDLE
笔记
如果您在命令行、配置文件中显式使用参数,并且相应的环境变量包含一个值,则 xbcloud将使用命令行或配置文件中提供的值。
OpenStack 环境变量也被识别并自动映射到相应的swift参数 ( --storage=swift
)。
- OS_AUTH_URL
- OS_TENANT_NAME
- OS_TENANT_ID
- OS_USERNAME
- OS_PASSWORD
- OS_USER_DOMAIN
- OS_USER_DOMAIN_ID
- OS_PROJECT_DOMAIN
- OS_PROJECT_DOMAIN_ID
- OS_REGION_NAME
- OS_STORAGE_URL
- OS_CACERT
捷径
对于所有操作(put、get 和 delete),您可以使用快捷方式将存储类型、存储桶名称和备份名称指定为一个参数,而不是使用三个不同的参数(-storage、-s3-bucket 和备份名称本身)。
使用快捷语法提供存储类型、存储桶和备份名称
使用以下格式:storage-type://bucket-name/backup-name
$ xbcloud get s3://operator-testing/bak22 ...
在本例中,s3是指存储类型,operator-testing是存储桶名称,bak22是备份名称。此快捷方式扩展如下:
$ xbcloud get --storage
=s3 --s3-bucket
=operator-testing bak22 ...
您不仅可以在命令行上提供强制参数。您可以使用配置文件和环境变量。
附加参数
xbcloud接受可用于任何存储类型的附加参数。该--md5
参数计算备份块的 MD5 哈希值。结果存储在遵循该backup_name.md5
模式的文件中。
$ xtrabackup --backup --stream
=xbstream
\
--parallel
=82
>backup.log
|xbcloud put s3://operator-testing/bak22
\
--parallel
=8--md5
2>upload.log
您可以使用该--header
参数在指定客户密钥时使用服务器端加密传递额外的 HTTP 标头。
使用 –header 进行 AES256 加密的示例
$ xtrabackup --backup --stream
=xbstream --parallel
=4|
\
xbcloud put s3://operator-testing/bak-enc/
\
--header
="X-Amz-Server-Side-Encryption-Customer-Algorithm: AES256"\
--header
="X-Amz-Server-Side-Encryption-Customer-Key: CuStoMerKey="\
--header
="X-Amz-Server-Side-Encryption-Customer-Key-MD5: CuStoMerKeyMd5=="\
--parallel
=8
该--header
参数对于设置访问控制列表 (ACL) 权限也很有用:--header="x-amz-acl: bucket-owner-full-control
使用 Swift 恢复
$ xbcloud get
[options
]<name>
[<list-of-files>
]|
xbstream -x
以下示例显示了如何从 Swift 获取和恢复备份:
$ xbcloud get --storage
=swift
\
--swift-container
=test\
--swift-user
=test:tester
\
--swift-auth-url
=http://192.168.8.80:8080/
\
--swift-key
=testing
\
full_backup
|xbstream -xv -C /tmp/downloaded_full
$ xtrabackup --prepare --target-dir
=/tmp/downloaded_full
$ xtrabackup --copy-back --target-dir
=/tmp/downloaded_full
使用Amazon S3恢复
$ xbcloud get s3://operator-testing/bak22
\
--s3-endpoint
=https://storage.googleapis.com/
\
--parallel
=102
>download.log
|xbstream -x -C restore --parallel
=8
增量备份
首先,进行作为增量备份基础的完整备份:
$ xtrabackup --backup --stream
=xbstream --extra-lsndir
=/storage/backups/
\
--target-dir
=/storage/backups/
|xbcloud put
\
--storage
=swift --swift-container
=test_backup
\
--swift-auth-version
=2.0 --swift-user
=admin
\
--swift-tenant
=admin --swift-password
=xoxoxoxo
\
--swift-auth-url
=http://127.0.0.1:35357/ --parallel
=10\
full_backup
然后进行增量备份:
$ xtrabackup --backup --incremental-basedir
=/storage/backups
\
--stream
=xbstream --target-dir
=/storage/inc_backup
|xbcloud put
\
--storage
=swift --swift-container
=test_backup
\
--swift-auth-version
=2.0 --swift-user
=admin
\
--swift-tenant
=admin --swift-password
=xoxoxoxo
\
--swift-auth-url
=http://127.0.0.1:35357/ --parallel
=10\
inc_backup
准备增量备份
要准备备份,请下载完整备份:
$ xbcloud get --swift-container
=test_backup
\
--swift-auth-version
=2.0 --swift-user
=admin
\
--swift-tenant
=admin --swift-password
=xoxoxoxo
\
--swift-auth-url
=http://127.0.0.1:35357/ --parallel
=10\
full_backup
|xbstream -xv -C /storage/downloaded_full
准备下载的完整备份:
$ xtrabackup --prepare --apply-log-only --target-dir
=/storage/downloaded_full
准备好完整备份后,下载增量备份:
$ xbcloud get --swift-container
=test_backup
\
--swift-auth-version
=2.0 --swift-user
=admin
\
--swift-tenant
=admin --swift-password
=xoxoxoxo
\
--swift-auth-url
=http://127.0.0.1:35357/ --parallel
=10\
inc_backup
|xbstream -xv -C /storage/downloaded_inc
准备增量备份:
$ xtrabackup --prepare --apply-log-only
\
--target-dir
=/storage/downloaded_full
\
--incremental-dir
=/storage/downloaded_inc
$ xtrabackup --prepare --target-dir
=/storage/downloaded_full
云备份的部分下载
如果您不想下载整个备份来恢复数据库,您可以只恢复特定的表:
$ xbcloud get --swift-container
=test_backup
--swift-auth-version
=2.0 --swift-user
=admin
\
--swift-tenant
=admin --swift-password
=xoxoxoxo
\
--swift-auth-url
=http://127.0.0.1:35357/ full_backup
\
ibdata1 sakila/payment.ibd
\
> /storage/partial/partial.xbs
$ xbstream -xv -C /storage/partial < /storage/partial/partial.xbs
此命令从完整备份中下载ibdata1
表和表。sakila/payment.ibd
命令行选项
xbcloud具有以下命令行选项:
–storage=[swift Amazon S3谷歌]
云存储选项。xbcloud支持 Swift、MinIO 和 AWS S3。默认值为swift
。
--swift-auth-url
Swift 集群的 URL。
--swift-url
重命名为 xbcloud –swift-auth-url
--swift-存储-url
xbcloud 尝试从 keystone 响应中获取指定区域(如果指定)的对象存储 URL。可以通过传递 --swift-storage-url=URL 参数来覆盖该 URL。
--swift-用户
Swift 用户名(X-Auth-User,特定于 Swift)
--快速键
Swift 密钥/密码(X-Auth-Key,特定于 Swift)
--swift-容器
要备份到的容器(特定于 Swift)
--并行=N
最大并发上传/下载请求数。默认为1
.
--cacert
带有 CA 证书的文件的路径
——不安全
不验证服务器证书
Swift 身份验证选项
Swift 规范描述了几种身份验证选项。xbcloud可以使用 API 版本 2 和 3 针对 keystone 进行身份验证。
--swift-auth-版本
指定 swift 认证版本。可能的值为:1.0
- TempAuth、2.0
- Keystone v2.0 和3
- Keystone v3。默认值为 1.0
。
对于 v2,其他选项包括:
–swift-租户
Swift 租户名称。
--swift-租户 ID
Swift 租户 ID。
--swift-区域
Swift 端点区域。
--swift-密码
用户的 Swift 密码。
对于 v3,其他选项包括:
--swift-user-id
快速用户 ID。
--swift-项目
斯威夫特项目名称。
--swift-project-id
Swift 项目 ID。
--swift 域
迅捷域名。
--swift-domain-id
Swift 域 ID。
指数退避
此功能在 xbcloud 二进制文件的Percona XtraBackup 2.4.24中实现。
指数退避增加了完成备份或恢复操作的机会。例如,如果您的网络连接不稳定或其他网络问题,则区块上传或下载可能会失败。此功能添加指数退避或睡眠时间,然后重试上传或下载。
当块上传或下载操作失败时,xbcloud 会检查失败的原因。此失败可能是 CURL 错误或 HTTP 错误,或特定于客户端的错误。如果错误列在可重试错误列表中,xbcloud 会暂停一段计算的时间,然后重试操作,直到该时间达到该--max-backoff
值。
将重试该操作,直到--max-retries
达到该值。如果块操作在最后一次重试时失败,xbcloud 将中止该进程。
默认值如下:
- –max-backoff = 300000(5 分钟)
- – 最大重试次数 = 10
您可以通过添加参数来调整重试次数,并通过将参数添加到 xbcloud 命令来--max-retries
调整重试之间的最大时间长度。--max-backoff
由于 xbcloud 并行执行多个异步请求,因此以毫秒为单位的计算值用于max-backoff
. 该算法计算在下一次重试之前休眠多少毫秒。生成的数字基于二 (2) 的幂、已尝试重试的次数并添加一个介于 1 和 1000 之间的随机数。如果多个块具有相同的退避值,该数字可避免网络拥塞。如果使用默认值,则最终重试尝试大约在第一次尝试后 17 分钟。当毫秒数达到设置时,不再计算该数字--max-backoff
。此时,使用--max-backoff
设置继续重试,直到max-retries
达到参数。
可重试的错误
我们重试以下 CURL 操作:
- CURLE_GOT_NOTHING
- CURLE_OPERATION_TIMEOUT
- CURLE_RECV_ERROR
- CURLE_SEND_ERROR
- CURLE_SEND_FAIL_REWIND
- CURLE_PARTIAL_FILE
- CURLE_SSL_CONNECT_ERROR
我们重试以下 HTTP 操作状态码:
- 503
- 500
- 504
- 408
每个云提供商可能会返回不同的 CURL 错误或 HTTP 错误,具体取决于问题。通过设置以下变量--curl-retriable-errors
或--http-retriable-errors
在命令行上或在my.cnf
[xbcloud] 部分下的自定义配置文件中添加新错误。
使用--verbose
输出时增强了错误处理。此输出指定导致 xbcloud 失败的错误以及用户必须添加什么参数才能重试此错误。
以下是详细输出的示例:
21070114
:34:23 /work/pxb/ins/2.4/bin/xbcloud: Operation failed. Error: Server returned nothing
(no headers, no data
)
21070114
:34:23 /work/pxb/ins/2.4/bin/xbcloud: Curl error
(52)Server returned nothing
(no headers, no data
)is not configured as retriable. You can allow it by adding --curl-retriable-errors
=52parameter
例子
以下示例调整最大重试次数和重试之间的最长时间。
xbcloud
[options
]--max-retries
=5--max-backoff
=10000
以下文本是与命令一起使用的指数退避的示例:
21070210
:07:05 /work/pxb/ins/2.4/bin/xbcloud: Operation failed. Error: Server returned nothing
(no headers, no data
)
21070210
:07:05 /work/pxb/ins/2.4/bin/xbcloud: Sleeping
for2384
ms before retrying backup3/xtrabackup_logfile.00000000000000000006
[1]
. . .
21070210
:07:23 /work/pxb/ins/2.4/bin/xbcloud: Operation failed. Error: Server returned nothing
(no headers, no data
)
21070210
:07:23 /work/pxb/ins/2.4/bin/xbcloud: Sleeping
for4387
ms before retrying backup3/xtrabackup_logfile.00000000000000000006
[2]
. . .
21070210
:07:52 /work/pxb/ins/2.4/bin/xbcloud: Operation failed. Error: Failed sending data to the peer
21070210
:07:52 /work/pxb/ins/2.4/bin/xbcloud: Sleeping
for8691
ms before retrying backup3/xtrabackup_logfile.00000000000000000006
[3]
. . .
21070210
:08:47 /work/pxb/ins/2.4/bin/xbcloud: Operation failed. Error: Failed sending data to the peer
21070210
:08:47 /work/pxb/ins/2.4/bin/xbcloud: Sleeping
for10000
ms before retrying backup3/xtrabackup_logfile.00000000000000000006
[4]
. . .
21070210
:10:12 /work/pxb/ins/2.4/bin/xbcloud: successfully uploaded chunk: backup3/xtrabackup_logfile.00000000000000000006, size:
8388660
以下列表详细说明了示例输出:
[1.] Chunkxtrabackup_logfile.00000000000000000006
第一次上传失败,休眠了2384毫秒。
[2.] 同一个chunk第二次失败,时间增加到4387毫秒。
[3.] 同一个chunk第三次失败,时间增加到8691毫秒。
[4.] 同一个块第四次失败。=10000 ,max-backoff
它将最大休眠时间定义为 10000。任何重试在达到该参数后都会休眠相同的时间。
[5.] 相同的块上传成功。
将 xbcloud 二进制文件与 Microsoft Azure 云存储一起使用
此功能是技术预览质量。
在 Percona XtraBackup 2.4.25 中实现的xbcloud二进制文件使用 REST API 添加了对 Microsoft Azure 云存储的支持。
选项
以下是使用 REST API 将备份上传到 Azure 的选项、环境变量和说明。环境变量由xbcloud识别,它会自动将它们映射到相应的参数:
选项名称 |
环境变量 |
描述 |
|
AZURE_STORAGE_ACCOUNT |
Azure 存储帐户是用于访问和存储 Azure 数据对象的唯一命名空间。 |
|
AZURE_CONTAINER_NAME |
容器名称是符合Azure 命名规则的有效 DNS 名称 |
|
AZURE_ACCESS_KEY |
生成的密钥,可用于授权使用共享密钥授权访问您帐户中的数据。 |
|
AZURE_ENDPOINT |
端点允许客户端安全地访问数据。 |
|
AZURE_STORAGE_CLASS |
云层可以在保持性能的同时减少所需的本地存储。启用后,此功能具有以下类别: |
使用Azurite 开源模拟器测试您的
Azure 应用程序。出于测试目的,xbcloud二进制文件添加了--azure-development-storage
使用默认值access_key
和storage account
azurite
以及testcontainer
容器的选项。如果需要,您可以覆盖这些选项。
用法
可以使用xbcloud的所有可用选项,例如并行、最大重试次数等。有关详细信息,请参阅xbcloud 二进制文件。
例子
xbcloud备份的示例。
$ xtrabackup --backup --stream
=xbstream --target-dir
=$TARGET_DIR
|
xbcloud put backup_name --azure-storage-account
=pxbtesting --azure-access-key
=$AZURE_KEY--azure-container-name
=test--storage
=azure
从xbcloud恢复备份的示例。
$ xbcloud get backup_name --azure-storage-account
=pxbtesting --azure-access-key
=$AZURE_KEY--azure-container-name
=test--storage
=azure --parallel
=102
>download.log
|xbstream -x -C restore
从xbcloud删除备份的示例。
$ xbcloud delete backup_name --azure-storage-account
=pxbtesting --azure-access-key
=$AZURE_KEY--azure-container-name
=test--storage
=azure
使用快捷方式还原的示例。
$ xbcloud get azure://operator-testing/bak22 ...
xbcrypt 二进制文件
为了支持备份的加密和解密,Percona XtraBackupxbcrypt
引入了一个新工具。
Percona XtraBackup 2.4.25 实现了 XBCRYPT_ENCRYPTION_KEY 环境变量。该变量仅用于代替--encrypt_key=name
选项。您可以使用环境变量或命令行选项。如果两者都使用,则命令行选项优先于环境变量中指定的值。
该实用程序以xbstream 二进制文件为模型,用于在Percona XtraBackup之外执行加密和解密。xbcrypt
具有以下命令行选项:
-d, –解密
解密数据输入到输出。
-i,--输入=名称
可选输入文件。如果未指定,输入将从标准输入中读取。
-o,--输出=名称
可选的输出文件。如果未指定,输出将被写入标准输出。
-a,--加密算法=名称
加密演算法。
-k,--加密密钥=名称
加密密钥。
-f,--加密密钥文件=名称
包含加密密钥的文件。
-s,--加密块大小=
用于加密的工作缓冲区大小(以字节为单位)。默认值为 64K。
--加密线程=
此选项指定将用于并行加密/解密的工作线程数。
-v,--详细
显示详细状态输出。
xbstream 二进制文件
为了支持同时压缩和流式传输,除了 TAR 格式之外,Percona XtraBackup还引入了一种称为 xbstream 的新自定义流式传输格式。这需要克服传统存档格式的一些限制,例如 tar、cpio 和其他不允许流式传输动态生成的文件,例如动态压缩文件。xbstream 与传统流/存档格式相比的其他优势包括同时流式传输多个文件的能力(因此可以将 xbstream 格式的流与 -parallel 选项一起使用)和更紧凑的数据存储。
该实用程序具有类似 tar 的界面:
- 使用该
-x
选项,它将从从其标准输入读取的流中提取文件到当前目录,除非该-c
选项另有指定。Percona XtraBackup 2.4.7--parallel
中已经实现了对使用该选项进行并行提取的支持。 - 使用该
-c
选项,它将命令行上指定的文件流式传输到其标准输出。 - 使用
--decrypt=ALGO
指定的选项 xbstream 将在提取输入流时自动解密加密文件。此选项支持的值为:AES128
、AES192
和AES256
。必须指定其中一个或选项以提供加密密钥,但不能同时指定两者--encrypt-key
。--encrypt-key-file
此选项已在Percona XtraBackup 2.4.7 中实现。 - 使用该
--encrypt-threads
选项,您可以指定并行数据加密的线程数。默认值为1
。此选项已在Percona XtraBackup 2.4.7 中实现。 - 该
--encrypt-key
选项用于指定将使用的加密密钥。它不能与--encrypt-key-file
选项一起使用,因为它们是互斥的。此选项已在 Percona XtraBackup 2.4.7 中实现。 - 该
--encrypt-key-file
选项用于指定包含加密密钥的文件。它不能与--encrypt-key
选项一起使用,因为它们是互斥的。此选项已在Percona XtraBackup 2.4.7 中实现。
posix_fadvise()
该实用程序还尝试通过在可用时使用适当的调用来最小化其对操作系统页面缓存的影响。
当使用xtrabackup启用压缩时,所有数据都将使用指定的压缩算法进行压缩,包括事务日志文件和元数据文件。当前唯一支持的算法是quicklz
.
生成的文件具有 qpress 存档格式,即xtrabackup\*.qp
生成的每个文件本质上都是一个单文件 qpress 存档,并且可以由qpress 文件存档器提取和解压缩。这意味着不需要解压缩整个备份来恢复单个表,就像使用.tar.gz
文件可以使用可以从 这里下载的qpress工具解压缩。Qpress 支持多线程解压。
块文件的默认大小为 10MB。
笔记
用于--read-buffer-size
调整块大小。
如果您使用加密,请同时指定--read-buffer-size
和--encrypt-chunk-size
选项来调整块大小。
已知问题和限制
压缩InnoDB表存在许多与Percona XtraBackup相关的问题 。这些问题是由服务器端错误或操作系统配置引起的,因此无法在Percona XtraBackup端修复。
已知的问题:
- 对于MySQL或Percona Server for MySQL版本 5.1 和 5.5,存在已知和未修复的错误,包括对压缩InnoDB表的更新的重做日志记录。例如,内部 Oracle 错误 #16267120 仅在MySQL 5.6.12 中修复,但在 5.1 或 5.5 中未修复。
MLOG_ZIP_PAGE_REORGANIZE
该错误是关于未在页面重组时记录的压缩页面图像,因此,如果在重放重做日志记录时使用不同的 zlib 版本,恢复过程可能会失败。 - 对于MySQL或Percona Server for MySQL 5.6 版,不建议为使用由Percona XtraBackup 备份的
innodb_log_compressed_pages=OFF
压缩InnoDB表的服务器设置。此选项使 InnoDB恢复(因此,备份准备)对版本敏感。如果执行备份准备的主机使用的 版本与服务器在运行时使用的版本不同,则备份准备可能会由于压缩算法的差异而失败。zlibzlib
OPTIMIZE TABLE
如果在运行时(错误https://bugs.launchpad.net/percona-xtrabackup/+bug/1541763)或ALTER TABLE ... TABLESPACE
(错误PXB-1360)在该表上进行备份,则无法恢复备份的表数据。- 由于错误PXB-372,紧凑备份当前无法工作。
- 备份失败并显示
Error 24: 'Too many open files'
. 这通常发生在正在备份的数据库包含大量文件并且Percona XtraBackup无法打开所有文件以创建成功备份时。为了避免此错误,应适当配置操作系统,以便Percona XtraBackup可以打开其所有文件。在 Linux 上,这可以通过ulimit
特定备份会话的命令或通过编辑 /etc/security/limits.conf 以全局更改它来完成(注意:可以设置的最大可能值1048576
是硬编码常量在 Linux 内核中)。
xtrabackup
二进制文件有一些您应该注意的限制,以确保您的备份顺利进行并且是可恢复的。
限制:
- Aria 存储引擎是MariaDB的一部分,已集成多年,2011 年innobackupex添加了 Aria 表文件备份支持。问题是引擎使用了未备份的恢复日志文件和 aria_log_control 文件通过xtrabackup。如文档中所述,在没有文件的情况下启动MariaDB
maria_log_control
会将所有 Aria 表标记为在CHECK
表上执行以下错误时已损坏:Table is from another system and must be zerofilled or repaired to be usable on this system
. 这意味着来自xtrabackup备份的 Aria 表必须在可用之前进行修复(这可能会很长,具体取决于表的大小)。另一种选择是aria_chk --zerofil table
在准备阶段后备份中存在的所有 Aria 表上。 - 如果
xtrabackup_logfile
大于 4GB,则该--prepare
步骤将在 32 位版本上失败xtrabackup
。 xtrabackup
不理解--set-variable
my.cnf
MySQL 使用的非常古老的语法。请参阅配置 xtrabackup。
经常问的问题
我是否需要 InnoDB 热备份许可证才能使用 Percona XtraBackup?
不。虽然innobackupex
源自 InnoDB Hot Backup 使用的相同 GPL 和开源包装脚本,但它不执行ibbackup
,并且xtrabackup
二进制文件不执行或链接到ibbackup
. 您无需任何许可即可使用Percona XtraBackup ;它与 InnoDB 热备份完全分开。
innobackupex 和 innobackup 有什么区别?
innobackupex 二进制文件是Oracle innobackup 脚本(重命名为 mysqlbackup)的修补版本。它们是相似的,熟悉 innobackup 可能会有所帮助。
除了innobackupex特定功能的可用选项外,主要区别在于:
- 打印到
STDERR
而不是STDOUT
启用该innobackupex --stream
选项 - 检测配置文件——
my.cnf
自动(或用 设置innobackupex --defaults-file
)而不是要求配置文件作为第一个参数 - 默认将xtrabackup作为二进制文件用于
innobackupex --ibbackup
有关更多详细信息,请参阅innobackupex 选项参考。
哪些基于 Web 的备份工具基于 Percona XtraBackup?
Zmanda Recovery Manager是一个商业工具,它使用Percona XtraBackup进行非阻塞备份:
“ZRM 使用Percona XtraBackup为 MySQL 的非阻塞备份提供支持。带有Percona XtraBackup的ZRM通过提供基于每秒 IO 操作数的限制来提供资源利用率管理。即使备份是在数据库级别完成的,基于Percona XtraBackup的备份也允许进行表级恢复。此操作要求恢复数据库服务器是Percona Server for MySQL with XtraDB。”
xtrabackup二进制文件因浮点异常而失败
在大多数情况下,这是由于没有通过xtrabackup安装所需的库(和版本) 。使用支持库安装GCC套件并重新编译xtrabackup将解决该问题。有关该过程的说明,请参阅从源代码编译和安装。
ibdata/ib_log
如果文件不在 MySQL 数据目录中,xtrabackup 如何处理恢复时的文件?
如果ibdata
和ib_log
文件位于 datadir 之外的不同目录中,则在应用日志后将它们移动到适当的位置。
备份失败并出现错误 24:“打开的文件太多”
当正在备份的数据库包含大量文件并且Percona XtraBackup无法打开所有文件以创建成功备份时,通常会发生此错误。为了避免此错误,应适当配置操作系统,以便Percona XtraBackup可以打开其所有文件。在 Linux 上,这可以通过ulimit
特定备份会话的命令或通过编辑 /etc/security/limits.conf 以全局更改它来完成
笔记
可以设置的最大可能值是1048576
Linux 内核中的硬编码常量。
如何处理跳过 DDL 操作的重做日志?
为了防止在运行 DDL 操作时创建损坏的备份,Percona XtraBackup 在检测到重做日志记录被禁用时会中止。在这种情况下,将打印以下错误:
[FATAL] InnoDB: An optimized (without redo logging) DDL operation has been performed. All modified pages may not have been flushed to the disk yet.
Percona XtraBackup will not be able to take a consistent backup. Retry the backup operation.
笔记
在排序索引构建期间禁用重做日志记录
为了避免这个错误,Percona XtraBackup 可以在复制表时对表使用元数据锁:
- 要阻止所有 DDL 操作,请使用
xtrabackup --lock-ddl
发出LOCK TABLES FOR BACKUP
. - 如果
LOCK TABLES FOR BACKUP
不支持,您可以在 XtraBackup 开始复制每个表之前阻止每个表的 DDL,直到使用该xtrabackup --lock-ddl-per-table
选项完成备份。 - 与备份和服务器相关的信息
backup-my.cnf
Percona XtraBackup 创建的文件索引
此文件包含在xtrabackup --prepare
. 这不是原始的备份my.cnf
。InnoDB 配置是从 backup-my.cnf
备份时由 innobackupex 创建的文件中读取的。默认情况下 xtrabackup --prepare
使用 InnoDB 配置 ,如果指定,则使用 from 。在这种情况下,InnoDB 配置是指影响数据格式的服务器变量,即选项 等。与位置相关的变量,例如 或 总是被 忽略,因此准备备份总是使用备份目录中的数据文件,而不是任何外部文件.backup-my.cnfxtrabackup --defaults-fileinnodb_page_sizeinnodb_log_block_sizeinnodb_log_group_home_dirinnodb_data_file_pathxtrabackup --prepare
xtrabackup_checkpoints
备份的类型(例如完整或增量)、其状态(例如已准备好)以及其中包含的 LSN 范围。此信息用于增量备份。xtrabackup_checkpoints
进行完整备份后的示例:
backup_type = full-backuped
from_lsn = 0
to_lsn = 15188961605
last_lsn = 15188961605
xtrabackup_checkpoints
进行增量备份后的 示例:
backup_type = incremental
from_lsn = 15188961605
to_lsn = 15189350111
last_lsn = 15189350111
xtrabackup_binlog_info
服务器使用的二进制日志文件及其在备份时的位置。的结果SHOW MASTER STATUS
。
xtrabackup_binlog_pos_innodb
InnoDB或 XtraDB 表的二进制日志文件及其当前位置。
xtrabackup_binary
进程中使用的xtrabackup二进制文件。
xtrabackup_logfile
包含运行所需的数据:xtrabackup --prepare
。该文件越大,该xtrabackup --prepare
过程将需要更长的时间才能完成。
<table_name>.delta.meta
该文件将在执行增量备份时创建。它包含每个表的增量元数据:页面大小、压缩页面的大小(如果值为 0,则表示表空间未压缩)和空间 ID。此文件的示例可能如下所示:
page_size = 16384
zip_size = 0
space_id = 0
- 与复制环境相关的信息(如果使用该
xtrabackup --slave-info
选项):xtrabackup_slave_info
CHANGE MASTER
设置从站所需的语句。
- 与Galera和Percona XtraDB 集群相关的信息(如果使用该
xtrabackup --galera-info
选项):xtrabackup_galera_info
包含值wsrep_local_state_uuid
和 wsrep_last_committed
状态变量
商标政策
本商标政策旨在确保 Percona 品牌产品或服务的用户知道他们收到的内容确实是由 Percona 开发、批准、测试和维护的。商标通过将一家公司或个人的产品和服务与另一家公司或个人的产品和服务区分开来,有助于防止市场上的混乱。
Percona 拥有许多标志,包括但不限于 Percona、XtraDB、Percona XtraDB、XtraBackup、Percona XtraBackup、Percona Server 和 Percona Live,以及与这些标志相关的独特视觉图标和徽标。Percona 的未注册和注册商标均受到保护。
未经 Percona 书面许可,不得在名称、URL 或任何产品、服务、网站的其他识别特征或其他用途中使用任何 Percona 商标,以下三个有限的例外情况除外。
首先,在对真正的 Percona 产品进行命名合理使用引用时,您可以使用适当的 Percona 标志。
其次,当 Percona 根据 GNU 通用公共许可证(“GPL”)版本发布产品时,您可以在根据 GPL 的条款和条件分发该产品的逐字副本时使用适当的 Percona 标志。
第三,您可以使用适当的 Percona 标记来指代 GPL 发布的 Percona 软件的分发,该软件经过修改并进行了细微的更改,其唯一目的是允许该软件在 Percona 尚未支持的操作系统或硬件平台上运行发布软件,前提是这些第三方更改不影响软件的行为、功能、特性、设计或性能。购买此 Percona 品牌软件的用户将获得 Percona 软件的基本精确实施。
Percona 保留随时自行决定撤销此授权的权利。例如,如果 Percona 认为您的修改超出了本政策授予的有限许可范围,或者您对 Percona 标志的使用对 Percona 有害,Percona 将撤销该授权。撤销后,您必须立即停止使用适用的 Percona 标志。如果您在撤销后没有立即停止使用 Percona 标志,Percona 可能会采取行动保护其在 Percona 标志中的权利和利益。Percona 不授予将任何 Percona 标志用于 Percona 软件的任何其他修改版本的任何许可;此类使用需要我们事先书面许可。
商标法或本商标政策中规定的任何例外情况均不允许您截断、修改或以其他方式使用任何 Percona 商标作为您自己品牌的一部分。例如,如果 XYZ 创建了 Percona Server 的修改版本,则 XYZ 不得将该修改标记为“XYZ Percona Server”或“Percona XYZ Server”,即使该修改符合上述第三个例外。
在任何情况下,您都必须遵守不时修订的适用法律、基础许可和本商标政策。例如,对 Percona 商标的任何提及都应包括完整的商标名称、正确的拼写和大小写,以及对 Percona LLC 和/或其附属公司的所有权归属。例如,XtraBackup 的全称是 Percona XtraBackup。但是,为了简洁起见,在第二次和后续使用中省略“Percona”这个词是可以接受的,这样的省略不会引起混淆。
如果对本商标政策中概述的任何条件或例外情况有疑问,请联系trademarks@percona.com寻求帮助,我们将尽最大努力提供帮助。
版本检查
某些 Percona 软件包含“版本检查”功能,该功能使 Percona 软件用户能够收到可用软件更新的通知,以提高您的环境安全性和性能。除此之外,版本检查功能还为 Percona 提供与您正在运行的软件版本相关的信息,以及软件正在运行的环境确认。这有助于 Percona 能够根据客户社区内的趋势相应地集中我们的开发工作。
本文档的目的是阐明所收集的信息,并提供有关如何在需要时禁用此功能的指导。
用法
版本检查在 Percona Toolkit 2.1.4 中实现,并在 2.2.1 版本中默认启用。目前,Percona Toolkit、Percona XtraBackup 和 Percona Monitoring and Management (PMM)中的许多工具都支持它作为--[no]version-check
选项。
在启用版本检查的情况下启动时,支持此功能的工具通过安全的 HTTPS 通道连接到 Percona 的版本检查服务。它会比较本地安装的版本以查找可能的更新,并检查以下软件的版本:
- 操作系统
- Percona 监控和管理 (PMM)
- MySQL
- Perl
- Perl 的 MySQL 驱动程序 (DBD::mysql)
- Percona 工具包
然后,如果它们被识别为在环境中运行,它会检查并警告存在已知问题的版本。
服务器记录每个版本检查请求。存储的信息包括检查的系统唯一 ID,后跟软件名称和版本。ID 是在安装时或第一次提交版本检查查询时生成的。
笔记
在 Percona Toolkit 3.0.7 版本之前,系统 ID 是作为主机名的 MD5 哈希计算的,从 Percona Toolkit 3.0.7 开始,它是作为随机数的 MD5 哈希生成的。Percona XtraBackup 继续使用基于主机名的 MD5 哈希。
结果,发送的查询内容如下:
85624f3fb5d2af8816178ea1493ed41a;DBD::mysql;4.044
c2b6d625ef3409164cbf8af4985c48d3;MySQL;MySQL Community Server (GPL) 5.7.22-log
85624f3fb5d2af8816178ea1493ed41a;OS;Manjaro Linux
85624f3fb5d2af8816178ea1493ed41a;Percona::Toolkit;3.0.11-dev
85624f3fb5d2af8816178ea1493ed41a;Perl;5.26.2
禁用版本检查
虽然版本检查功能不会收集任何个人信息,但您可能更愿意一次性或永久禁用此功能。要禁用它一次,--no-version-check
请在从支持它的 Percona 产品调用该工具时使用选项。这是一个简单的示例,它显示了在关闭版本检查的情况下从 Percona Toolkit运行pt-diskstats工具:
pt-diskstats --no-version-check
永久禁用版本检查可以通过将 no-version-check
选项放入 Percona 产品的配置文件中来完成(有关确切的文件名和语法,请参阅相应的文档)。例如,对于 Percona Toolkit,这可以 在全局配置文件中完成/etc/percona-toolkit/percona-toolkit.conf
:
# Disable Version Check for all tools:
no-version-check
在 Percona XtraBackup 的情况下,这可以在其配置文件 中以类似的方式完成:
[xtrabackup]
no-version-check
经常问的问题
为什么默认启用此功能?
我们相信启用此功能可以提高运行 Percona 软件的环境的安全性和性能,这对于大多数用户来说是一个不错的选择。
为什么不依赖操作系统的内置功能进行软件更新?
在许多环境中,操作系统存储库可能不包含最新版本的软件和通常手动安装的较新版本的软件,因此不会被操作系统范围的更新检查所覆盖。
为什么您发送的信息不仅仅是作为版本检查服务的一部分运行的软件版本?
兼容性问题可能由环境中各种组件的版本引起,例如有问题的 Perl、DBD 或 MySQL 版本可能会导致 Percona Toolkit 出现操作问题。