Uma pergunta que surge regularmente nos fóruns da Percona: Toda node em um Percona XtraDB Cluster (PXC) precisa ter o XtraBackup instalado? É uma pergunta justa, especialmente ao gerenciar um ambiente misto ou tentar minimizar a pegada de software em certas nodes. Aqui está o que a mecânica real e os testes confirmam.
A Resposta Curta (Mas Continue Lendo)
Depende do que você quer que essa node faça. A nuance importa bastante aqui, então vale a pena percorrer como funciona a State Snapshot Transfer (SST) no PXC e por que a presença — ou ausência — do XtraBackup em uma node específica é significativa.
Uma Refrescada Rápida sobre SST no PXC
Quando uma nova node se junta a um Percona XtraDB Cluster, ou quando uma node existente ficou inativa por tempo suficiente para que o Incremental State Transfer (IST) não seja mais possível, o cluster executa uma State Snapshot Transfer (SST). Isso é essencialmente uma cópia completa de dados de uma node doadora para a node receptora.
O PXC suporta múltiplos métodos SST, configurados em my.cnf:
[mysqld]
wsrep_sst_method = xtrabackup-v2
Os métodos SST disponíveis incluem:
- xtrabackup-v2 — O método recomendado para PXC, usando Percona XtraBackup; executa SST sem bloquear a node doadora por períodos prolongados
- clone — Disponível no PXC 8.0.22+ usando o Clone Plugin integrado do MySQL; remove a dependência do XtraBackup para SST
- mysqldump — Mais lento e bloqueia a node doadora durante a transferência; não recomendado para produção
- rsync — Requer que a node doadora esteja em modo somente-leitura durante a transferência, bloqueando escritas; também não recomendado para clusters ativos
O método xtrabackup-v2 tem sido historicamente a abordagem padrão e permanece amplamente usado em implantações existentes precisamente porque mantém a node doadora disponível para escritas durante a transferência. Os outros métodos legados podem bloquear escritas na node doadora, o que geralmente é inaceitável em um cluster de produção. Note que a Percona tem recomendado cada vez mais o método clone para novas instalações no PXC 8.0.22 e posterior, pois remove a dependência de ferramenta externa na camada SST.
Onde o XtraBackup Precisa Estar Instalado?
Quando um SST usando xtrabackup-v2 é acionado, tanto a node doadora quanto a node receptora precisam ter o XtraBackup instalado e acessível. Aqui está o porquê ambos os lados estão envolvidos:
- O doador executa o XtraBackup para transmitir os dados do snapshot para fora
- O receptor executa o XtraBackup — especificamente as utilidades
xbstreamexbcrypt— para receber e aplicar esses dados transmitidos
Se o nó receptor não tiver o XtraBackup instalado e você tentar trazê-lo para o cluster usando xtrabackup-v2, o SST falhará. O log de erros no receptor geralmente mostrará algo assim:
[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)
Essa é uma falha clara e inequívoca. Se o xbstream não estiver presente no receptor, o SST não será concluído.
E os Nós que Nunca Serão Receptores?
Tecnicamente, se um nó sempre atuar como doador e nunca precisar se juntar novamente ao cluster do zero, você poderia argumentar que ele só precisa do XtraBackup em sua capacidade de doador. Na prática, no entanto, qualquer nó pode se tornar um receptor — após uma falha, após manutenção planejada ou após recuperação de uma partição de rede. Não há como garantir de forma confiável que um nó nunca precisará receber um SST.
A orientação prática aqui é direta: instale o XtraBackup em todos os nós PXC, sem exceção. O custo de tê-lo instalado é insignificante. O custo de um SST falhado durante uma interrupção não planejada não é.
A Alternativa do Plugin Clone (PXC 8.0.22+)
A partir do PXC 8.0.22, a Percona adicionou suporte ao MySQL Clone Plugin como método SST. Vale a pena conhecer porque isso remove completamente a dependência do XtraBackup para fins de SST:
[mysqld]
wsrep_sst_method = clone
Com o método clone, o Plugin Clone deve ser carregado em todos os nós:
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
SHOW PLUGINS WHERE Name = 'clone';
+-------+--------+-------+----------------+---------+
| Name | Status | Type | Library | License |
+-------+--------+-------+----------------+---------+
| clone | ACTIVE | CLONE | mysql_clone.so | GPL |
+-------+--------+-------+----------------+---------+
O método clone é uma opção sólida para padronizar sem o XtraBackup como dependência SST. Dito isso, o XtraBackup ainda tem valor real para sua estratégia de backup externo, independentemente do método SST que você escolher. O SST é um mecanismo de sincronização de cluster — não é um backup e nunca deve ser tratado como tal.
Verificando Sua Configuração Atual de SST
Você pode verificar seu método SST atual e configurações relacionadas ao Galera com:
SHOW VARIABLES LIKE 'wsrep_sst_method';
+------------------+---------------+
| Variable_name | Value |
+------------------+---------------+
| wsrep_sst_method | xtrabackup-v2 |
+------------------+---------------+
Para verificar o estado do cluster e confirmar qual nó pode estar atuando como doador:
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 |
+--------------------+-------+
Observações Práticas
Algumas coisas que valem a pena notar ao trabalhar diretamente com ambientes PXC:
``````html- A versão do XtraBackup deve corresponder à sua versão do PXC. Usar XtraBackup 2.x com PXC 8.0 causará falhas no SST. Use Percona XtraBackup 8.0 com PXC 8.0 e confirme o alinhamento das versões após qualquer atualização.
- Mesmo se você mudar para o método SST
clone, mantenha o XtraBackup instalado para backups programados. Sua estratégia de backup e seu método SST são preocupações separadas e devem ser tratadas como tal. - A variável
wsrep_sst_donorpermite que você especifique um nó doador preferencial, o que é útil para direcionar o SST para longe do seu membro mais ocupado ou mais sensível à latência. - Se você estiver executando o Percona Toolkit junto com o PXC, esteja ciente de como a replicação DDL funciona na sua versão específica do PXC — o comportamento do Total Order Isolation (TOI) versus Rolling Schema Upgrade (RSU) difere e merece uma análise dedicada antes de executar alterações de esquema em produção.
Resumo
Para responder à pergunta diretamente: se você estiver usando xtrabackup-v2 como seu método SST — que permanece o padrão em muitas implantações existentes do PXC —, sim, o XtraBackup precisa ser instalado em todos os membros do cluster. Qualquer nó pode ser doador ou joiner dependendo das circunstâncias, e ambos os papéis exigem a presença do XtraBackup ao usar este método.
Se você estiver no PXC 8.0.22 ou posterior e quiser eliminar essa dependência na camada SST, o método Clone Plugin é uma alternativa viável e é cada vez mais a escolha recomendada pela Percona para novas implantações. Se você estiver começando do zero, o PXC 8.4 LTS é a versão de suporte de longo prazo atual e o alvo recomendado para novas instalações. Mesmo ao usar clone para SST, o XtraBackup continua sendo a ferramenta certa para seus jobs de backup reais.
Não tente economizar alguns megabytes de espaço em disco pulando o XtraBackup em nós selecionados. A falha no SST que eventualmente resulta dessa decisão não é uma troca que valha a pena fazer.
