Percona 论坛中经常出现的一个问题：Percona XtraDB Cluster (PXC) 中的每个节点都需要安装 XtraBackup 吗？ 这是一个合理的问题，尤其是在管理混合环境或试图最小化某些节点上的软件占用时。以下是实际机制和测试所确认的内容。
简短答案（但请继续阅读）
这取决于你希望该节点做什么。 这里的细微差别非常重要，因此值得详细说明 PXC 中 State Snapshot Transfer (SST) 的工作原理，以及 XtraBackup 在给定节点上的存在——或缺失——为什么重要。
PXC 中 SST 的快速复习
当一个新节点加入 Percona XtraDB Cluster，或者一个现有节点宕机时间过长以至于 Incremental State Transfer (IST) 不再可能时，集群会执行 State Snapshot Transfer (SST)。这本质上是捐献节点向加入节点的全量数据复制。
PXC 支持多种 SST 方法，在 my.cnf 中配置：
[mysqld]
wsrep_sst_method = xtrabackup-v2
可用的 SST 方法包括：
- xtrabackup-v2 — PXC 的推荐方法，使用 Percona XtraBackup；执行 SST 时不会长时间锁定捐献节点
- clone — PXC 8.0.22+ 中可用，使用 MySQL 内置的 Clone Plugin；消除了 SST 对 XtraBackup 的依赖
- mysqldump — 较慢且在传输期间锁定捐献节点；不推荐用于生产环境
- rsync — 要求捐献节点在传输期间为只读，阻塞写入；也不推荐用于活跃集群
xtrabackup-v2 方法历来是默认方法，并在现有部署中广泛使用，正是因为它在传输期间保持捐献节点可用于写入。其他旧方法可能会阻塞捐献节点的写入，这在生产集群中通常是不可接受的。请注意，Percona 越来越推荐在 PXC 8.0.22 及更高版本的新安装中使用 clone 方法，因为它消除了 SST 层对外部工具的依赖。
XtraBackup 需要安装在哪里？
当触发使用 xtrabackup-v2 的 SST 时，捐献节点和加入节点都需要安装 XtraBackup 并可访问。以下是为什么两侧都需要的原因：
- 捐赠者 运行 XtraBackup 来流式传输快照数据到外部
- 加入者 运行 XtraBackup — 具体来说是
xbstream和xbcrypt工具 — 来接收并应用这些流式传输的数据
如果加入者节点没有安装 XtraBackup，并且您尝试使用 xtrabackup-v2 将其加入集群，SST 将失败。加入者上的错误日志通常会显示类似以下内容：
[ERROR] WSREP: Failed to read 'ready <addr>' from: wsrep_sst_xtrabackup-v2
...
wsrep_sst_xtrabackup-v2: line 522: xbstream: command not found
[ERROR] WSREP: SST failed: 2 (No such file or directory)
这是一个明确且无歧义的失败模式。如果 xbstream 在加入者上不存在，SST 将无法完成。
那些永远不会成为加入者的节点呢？
从技术上讲，如果一个节点将始终充当捐赠者并且永远不需要从头重新加入集群，您可以说它只需要在捐赠者角色下安装 XtraBackup。然而，在实际操作中，任何节点都可能成为加入者 — 在崩溃后、计划维护后，或从网络分区恢复后。没有可靠的方法可以保证一个节点永远不需要接收 SST。
这里的实用指导很简单：在每个 PXC 节点上无一例外地安装 XtraBackup。 安装它的开销微乎其微。而在计划外中断期间 SST 失败的成本则不然。
Clone 插件替代方案（PXC 8.0.22+）
从 PXC 8.0.22 开始，Percona 添加了对 MySQL Clone Plugin 作为 SST 方法的支持。值得了解这一点，因为它完全消除了 SST 对 XtraBackup 的依赖：
[mysqld]
wsrep_sst_method = clone
使用 clone 方法时，所有节点必须加载 Clone 插件：
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
SHOW PLUGINS WHERE Name = 'clone';
+-------+--------+-------+----------------+---------+
| Name | Status | Type | Library | License |
+-------+--------+-------+----------------+---------+
| clone | ACTIVE | CLONE | mysql_clone.so | GPL |
+-------+--------+-------+----------------+---------+
clone 方法是一个很好的标准化选项，无需将 XtraBackup 作为 SST 依赖。不过，无论您选择哪种 SST 方法，XtraBackup 对于您的 外部备份策略 仍然具有真正价值。SST 是一种集群同步机制 — 它不是备份，也不应被当作备份对待。
检查当前的 SST 配置
您可以使用以下命令验证当前的 SST 方法和 Galera 相关设置：
SHOW VARIABLES LIKE 'wsrep_sst_method';
+------------------+---------------+
| Variable_name | Value |
+------------------+---------------+
| wsrep_sst_method | xtrabackup-v2 |
+------------------+---------------+
检查集群状态并确认哪个节点可能充当捐赠者：
SHOW STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
SHOW STATUS LIKE 'wsrep_connected';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| wsrep_connected | ON |
+-----------------+-------+
SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
实际观察
直接处理 PXC 环境时值得注意的几点：
``````html- XtraBackup 的版本必须与您的 PXC 版本匹配。使用 XtraBackup 2.x 与 PXC 8.0 会导致 SST 失败。请使用 Percona XtraBackup 8.0 与 PXC 8.0，并在任何升级后确认版本对齐。
- 即使您切换到
cloneSST 方法，也要保留安装 XtraBackup，用于计划备份。您的备份策略与 SST 方法是独立的关注点，应分别处理。 wsrep_sst_donor变量允许您指定首选捐赠节点，这对于将 SST 引导远离最繁忙或延迟最敏感的成员非常有用。- 如果您在 PXC 旁边运行 Percona Toolkit，请注意您特定 PXC 版本中 DDL replication 的工作方式 — Total Order Isolation (TOI) 与 Rolling Schema Upgrade (RSU) 的行为不同，在生产环境中运行架构更改之前值得专门查看。
总结
直接回答问题：如果您使用 xtrabackup-v2 作为 SST 方法 — 这在许多现有 PXC 部署中仍是默认方法 — 那么是的，每个集群成员都需要安装 XtraBackup。 任何节点都可能根据情况成为捐赠节点或加入节点，使用此方法时两种角色都需要 XtraBackup。
如果您使用 PXC 8.0.22 或更高版本，并希望在 SST 层消除该依赖，Clone Plugin 方法是一个可行的替代方案，并且是 Percona 越来越推荐的新部署选择。如果您是从头开始，PXC 8.4 LTS 是当前长期支持版本，也是新安装的推荐目标。即使使用 clone 进行 SST，XtraBackup 仍是实际备份任务的正确工具。
不要为了节省选定节点上的几兆字节磁盘空间而跳过 XtraBackup。此决定最终导致的 SST 失败不是值得的权衡。
