Una pregunta que surge regularmente en los foros de Percona: ¿Necesita cada nodo en un Percona XtraDB Cluster (PXC) tener XtraBackup instalado? Es una pregunta justa, especialmente cuando se gestiona un entorno mixto o se intenta minimizar la huella de software en ciertos nodos. Aquí está lo que confirman las mecánicas reales y las pruebas.
La respuesta corta (pero sigue leyendo)
Depende de lo que quieras que haga ese nodo. La sutileza importa mucho aquí, por lo que vale la pena repasar cómo funciona State Snapshot Transfer (SST) en PXC y por qué la presencia —o ausencia— de XtraBackup en un nodo dado es significativa.
Un repaso rápido sobre SST en PXC
Cuando un nuevo nodo se une a un Percona XtraDB Cluster, o cuando un nodo existente ha estado caído el tiempo suficiente como para que Incremental State Transfer (IST) ya no sea posible, el clúster realiza un State Snapshot Transfer (SST). Esto es esencialmente una copia completa de datos desde un nodo donante al nodo que se une.
PXC soporta múltiples métodos SST, configurados en my.cnf:
[mysqld]
wsrep_sst_method = xtrabackup-v2
Los métodos SST disponibles incluyen:
- xtrabackup-v2 — El método recomendado para PXC, usando Percona XtraBackup; realiza SST sin bloquear el donante por períodos extendidos
- clone — Disponible en PXC 8.0.22+ usando el Plugin Clone integrado de MySQL; elimina la dependencia de XtraBackup para SST
- mysqldump — Más lento y bloquea el donante durante la transferencia; no recomendado para producción
- rsync — Requiere que el donante esté en modo solo lectura durante la transferencia, bloqueando escrituras; tampoco recomendado para clústeres en vivo
El método xtrabackup-v2 ha sido históricamente el enfoque predeterminado y sigue siendo ampliamente utilizado en implementaciones existentes precisamente porque mantiene el nodo donante disponible para escrituras durante la transferencia. Los otros métodos legacy pueden bloquear escrituras en el donante, lo cual es generalmente inaceptable en un clúster de producción. Nota que Percona ha estado recomendando cada vez más el método clone para nuevas instalaciones en PXC 8.0.22 y posteriores, ya que elimina la dependencia de herramientas externas en la capa SST.
¿Dónde necesita estar instalado XtraBackup?
Cuando se activa un SST usando xtrabackup-v2, tanto el donante como el que se une necesitan tener XtraBackup instalado y accesible. Aquí está por qué ambos lados están involucrados:
- El donor ejecuta XtraBackup para transmitir los datos de la instantánea hacia afuera
- El joiner ejecuta XtraBackup — específicamente las utilidades
xbstreamyxbcrypt— para recibir y aplicar esos datos transmitidos
Si el nodo joiner no tiene XtraBackup instalado y intentas incorporarlo al clúster usando xtrabackup-v2, el SST fallará. El registro de errores en el joiner típicamente mostrará algo como esto:
[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)
Esa es una modalidad de fallo clara e inequívoca. Si xbstream no está presente en el joiner, el SST no se completará.
¿Qué pasa con los nodos que nunca serán joiners?
Técnicamente, si un nodo siempre actuará como donor y nunca necesitará reincorporarse al clúster desde cero, podrías argumentar que solo necesita XtraBackup en su capacidad de donor. Sin embargo, en la práctica, cualquier nodo puede convertirse en joiner — después de un fallo, después de mantenimiento planificado, o después de recuperarse de una partición de red. No hay forma confiable de garantizar que un nodo nunca necesite recibir un SST.
La guía práctica aquí es directa: instala XtraBackup en cada nodo PXC, sin excepción. La sobrecarga de tenerlo instalado es insignificante. El costo de un SST fallido durante una interrupción no planificada no lo es.
La alternativa del Plugin Clone (PXC 8.0.22+)
A partir de PXC 8.0.22, Percona agregó soporte para el MySQL Clone Plugin como método SST. Esto vale la pena saberlo porque elimina completamente la dependencia de XtraBackup para fines de SST:
[mysqld]
wsrep_sst_method = clone
Con el método clone, el Clone Plugin debe estar cargado en todos los nodos:
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
SHOW PLUGINS WHERE Name = 'clone';
+-------+--------+-------+----------------+---------+
| Name | Status | Type | Library | License |
+-------+--------+-------+----------------+---------+
| clone | ACTIVE | CLONE | mysql_clone.so | GPL |
+-------+--------+-------+----------------+---------+
El método clone es una opción sólida para estandarizar sin XtraBackup como dependencia SST. Dicho esto, XtraBackup aún tiene valor real para tu estrategia de respaldo externo independientemente del método SST que elijas. SST es un mecanismo de sincronización de clúster — no es un respaldo, y nunca debe tratarse como tal.
Verificando tu configuración SST actual
Puedes verificar tu método SST actual y configuraciones relacionadas con Galera con:
SHOW VARIABLES LIKE 'wsrep_sst_method';
+------------------+---------------+
| Variable_name | Value |
+------------------+---------------+
| wsrep_sst_method | xtrabackup-v2 |
+------------------+---------------+
Para verificar el estado del clúster y confirmar qué nodo puede estar actuando como 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 |
+--------------------+-------+
Observaciones prácticas
Algunas cosas que vale la pena notar de trabajar directamente con entornos PXC:
``````html- La versión de XtraBackup debe coincidir con la versión de PXC. Usar XtraBackup 2.x con PXC 8.0 provocará fallos en SST. Use Percona XtraBackup 8.0 con PXC 8.0 y confirme la alineación de versiones después de cualquier actualización.
- Incluso si cambia al método SST
clone, mantenga XtraBackup instalado para copias de seguridad programadas. Su estrategia de respaldo y su método SST son preocupaciones separadas y deben tratarse como tales. - La variable
wsrep_sst_donorle permite especificar un nodo donante preferido, lo cual es útil para dirigir SST lejos de su miembro más ocupado o sensible a la latencia. - Si está ejecutando Percona Toolkit junto con PXC, tenga en cuenta cómo funciona la replicación DDL en su versión específica de PXC — el comportamiento de Total Order Isolation (TOI) versus Rolling Schema Upgrade (RSU) difiere y merece una revisión dedicada antes de realizar cambios de esquema en producción.
Resumen
Para responder directamente a la pregunta: si está usando xtrabackup-v2 como su método SST — que sigue siendo el predeterminado en muchas implementaciones existentes de PXC — entonces sí, XtraBackup debe estar instalado en cada miembro del clúster. Cualquier nodo puede ser donante o unidor dependiendo de las circunstancias, y ambos roles requieren que XtraBackup esté presente al usar este método.
Si está en PXC 8.0.22 o posterior y desea eliminar esa dependencia en la capa SST, el método del Plugin Clone es una alternativa viable y cada vez más recomendada por Percona para nuevas implementaciones. Si está comenzando de cero, PXC 8.4 LTS es la versión de soporte a largo plazo actual y el objetivo recomendado para nuevas instalaciones. Incluso al usar clone para SST, XtraBackup sigue siendo la herramienta adecuada para sus trabajos reales de respaldo.
No intente ahorrar unos pocos megabytes de espacio en disco omitiendo XtraBackup en nodos seleccionados. El fallo de SST que eventualmente resulta de esa decisión no es un compromiso que valga la pena hacer.
