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はmy.cnfで設定される複数のSST方法をサポートしています：
[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以降の新規インストールに対して、SST層での外部ツール依存を除去するため、clone方法をますます推奨しています。
XtraBackupはどこにインストールする必要がありますか？
xtrabackup-v2を使用したSSTがトリガーされると、ドナーとジョイナーの両方にXtraBackupがインストールされ、アクセス可能である必要があります。両方が関与する理由は以下の通りです：
- donor（提供元）は XtraBackup を実行してスナップショットデータをアウトバウンドでストリーミングします
- joiner（参加元）は XtraBackup — 具体的には
xbstreamおよびxbcryptユーティリティ — を実行して、そのストリーミングされたデータを受信し適用します
joiner ノードに XtraBackup がインストールされていない場合、xtrabackup-v2 を使用してクラスタに追加しようとすると、SST が失敗します。joiner のエラーログには通常、次のような内容が表示されます：
[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 が joiner に存在しない場合、SST は完了しません。
参加元になることのないノードはどうでしょうか？
技術的には、ノードが常に donor（提供元）として動作し、ゼロからクラスタに再参加する必要がない場合、donor としての機能のみで XtraBackup が必要だと主張できます。しかし実際には、クラッシュ後、計画メンテナンス後、またはネットワークパーティションからの回復後、どのノードでも joiner になる可能性があります。ノードが 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 Plugin をロードする必要があります：
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 |
+------------------+---------------+
クラスタ状態を確認し、どのノードが donor（提供元）として動作しているかを確認するには：
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 が失敗します。PXC 8.0 には Percona XtraBackup 8.0 を使用し、アップグレード後はバージョン一致を確認してください。
- <
cloneSST メソッドに切り替えても、スケジュールされたバックアップのために XtraBackup をインストールしたままにしてください。バックアップ戦略と SST メソッドは別々の懸念事項であり、それぞれ独立して扱うべきです。 - <
wsrep_sst_donor変数は、好みのドナーノードを指定でき、最も忙しいかレイテンシに敏感なメンバーに SST を向けないようにするのに便利です。 - PXC とともに Percona Toolkit を実行している場合、特定の PXC バージョンでの DDL レプリケーションの動作に注意してください — 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 が現在の長期サポートリリースであり、新規インストールの推奨ターゲットです。SST に clone を使用していても、実際のバックアップジョブには XtraBackup が最適なツールです。
選択したノードで XtraBackup をスキップして数メガバイトのディスク容量を節約しようとしないでください。その決定が最終的に引き起こす SST 失敗は、犠牲にする価値のないトレードオフです。
