Introducción a Percona XtraBackup

En entornos de producción donde los volúmenes de datos superan los 50 GB o 100 GB, las estrategias tradicionales como mysqldump o las copias en frío resultan insuficientes debido al tiempo de inactividad que requieren. Para mitigar este impacto, es fundamental implementar un esquema de copias de seguridad incrementales. Percona XtraBackup surge como la solución estándar para realizar respaldos físicos en caliente (hot backups) compatibles con MySQL, Percona Server y MariaDB.

Esta herramienta de código abierto permite备份 (backup) sin bloquear las transacciones, aunque es importente notar que su funcionalidad se limita principalmente a motores de almacenamiento InnoDB y XtraDB. Las tablas MyISAM no soportan backup en caliente real con esta herramienta, aunque se incluyen en el proceso de copia de archivos.

Ventajas Clave de la Solución

• Eficiencia: Realiza copias físicas rápidas y fiables.
• Disponibilidad: No interrumpe las transacciones activas (non-blocking).
• Optimización: Soporta compresión para ahorrar ancho de banda y almacenamiento.
• Validación: Incluye verificación automática de la integridad del backup.
• Recuperación: Tiempos de restauración significativamente menores comparados con backups lógicos.
• Portabilidad: Facilita la transferencia de datos a servidores remotos.
• Rendimiento: Minimiza la carga adicional sobre el servidor de base de datos durante el proceso.

Arquitectura y Funcionamiento Interno

El proceso de backup involucra la interacción entre dos componentes principales: innobackupex (un script wrapper en Perl) y el binario xtrabackup. El flujo opertaivo se describe a continuación:

1. innobackupex inicia y genera un proceso hijo para ejecutar xtrabackup, quedando a la espera de la finalización de la copia de los archivos .ibd.
2. El binario xtrabackup despliega dos hilos principales: uno para copiar el log de redo (redo.log) desde el último checkpoint, y otro para copiar los datos de InnoDB. El hilo de redo inicia primero.
3. Una vez completada la copia de los datos InnoDB, xtrabackup notifica a innobackupex mediante la creación de un archivo señal.
4. Al recibir la señal, innobackupex ejecuta FLUSH TABLES WITH READ LOCK (FTWRL) para obtener un punto consistente y procede a copiar archivos no transaccionales (estructuras .frm, MyISAM, configuraciones, etc.). Durante esta fase, la base de datos está en modo solo lectura.
5. Tras copiar los archivos restantes, innobackupex notifica a xtrabackup para detener el hilo de copia del log de redo.
6. Finalmente, se liberan los locks (UNLOCK TABLES), se escriben los metadatos del backup y los procesos terminan limpiamente.

Implementación y Despliegue

Instalación del Paquete

La instalación puede realizarse mediante gestión de paquetes o compilación desde fuente. A continuación se muestra un ejemplo utilizando RPM en un sistema basado en RedHat/CentOS:

[admin@dbserver tools]$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
[admin@dbserver tools]$ sudo yum install -y percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm
[admin@dbserver tools]$ rpm -qa | grep xtrabackup
percona-xtrabackup-24-2.4.12-1.el7.x86_64

Es crucial distinguir las funciones de los binarios instalados:

• xtrabackup: Herramienta de bajo nivel para copiar datos InnoDB/XtraDB. No gestiona estructuras de tablas no InnoDB.
• innobackupex: Script que envuelve a xtrabackup, añadiendo soporte para MyISAM y gestión de archivos de definición de tablas.

Configuración de Usuario Dedicado

Por seguridad, se recomienda crear un usuario con privilegios mínimos exclusivos para备份:

mysql> CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'SecurePass123!';
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'backup_user'@'localhost';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost';
mysql> FLUSH PRIVILEGES;

Nota operativa: El servicio MySQL debe estar activo durante el backup. Para la restauración, el servicio debe estar detenido y el directorio de datos limpio, sin reinicializar.

Gestión de Copias Completas (Full Backup)

Una copia completa incluye todos los datos y archivos de registro necesarios para una restauración inmediata tras el proceso de preparación.

Ejecución del Backup

Se define un directorio base para almacenar las copias, por ejemplo, /srv/mysql_backups.

# Realizar backup completo
innobackupex --user=backup_user --password='SecurePass123!' --defaults-file=/etc/my.cnf /srv/mysql_backups/full

El sistema generará un subdirectorio con la marca de tiempo. Dentro se encontrarán archivos críticos como xtrabackup_checkpoints (estado LSN), xtrabackup_binlog_info (posición binlog) y backup-my.cnf.

Preparación de los Datos (Prepare)

Los datos respaldados pueden contener transacciones no confirmadas. El paso de "preparación" aplica los logs para asegurar la consistencia antes de la restauración.

# Aplicar logs para consistencia
innobackupex --apply-log /srv/mysql_backups/full/2023-11-15_09-00-00

Si el proceso finaliza correctamente, se mostrará el mensaje completed OK!. Opcionalmente, se puede asignar más memoria con --use-memory para acelerar esta fase.

Restauración de Datos

Para restaurar, se copian los archivos preparados al directorio de datos de MySQL (datadir).

# Detener servicio
systemctl stop mysqld

# Limpiar directorio destino (precaución)
rm -rf /var/lib/mysql/*

# Copiar archivos de backup
innobackupex --copy-back --defaults-file=/etc/my.cnf /srv/mysql_backups/full/2023-11-15_09-00-00

# Corregir permisos
chown -R mysql:mysql /var/lib/mysql

# Iniciar servicio
systemctl start mysqld

Estrategia de Copias Incrementales

Las copias incrementales se basan en el Número de Secuencia de Log (LSN) de InnoDB. Solo se respaldan las páginas modificadas desde el último backup. La cadena de restauración requiere una copia base completa seguida de todas las incrementales en orden.

Procedimiento de Backup Incremental

Primero se requiere una base completa. Luego, las incrementales apuntan al directorio de la copia anterior mediante --incremental-basedir.

# 1. Backup Base (Completo)
innobackupex --user=backup_user --password='SecurePass123!' /srv/mysql_backups/base

# 2. Primera Incremental (Basada en la base)
innobackupex --user=backup_user --password='SecurePass123!' --incremental /srv/mysql_backups/incr1 --incremental-basedir=/srv/mysql_backups/base/2023-11-15_09-00-00

# 3. Segunda Incremental (Basada en la anterior incremental)
innobackupex --user=backup_user --password='SecurePass123!' --incremental /srv/mysql_backups/incr2 --incremental-basedir=/srv/mysql_backups/incr1/2023-11-15_12-00-00

Al revisar el archivo xtrabackup_checkpoints en cada directorio, se puede observar el rango de LSN (from_lsn y to_lsn) que define qué datos fueron copiados.

Restauración con Incrementales

La preparación de incrementales es crítica. Se deben aplicar los logs de las incrementales sobre la base, pero con precaución en las transacciones no commitadas hasta el final.

# 1. Preparar la base (con redo-only para evitar rollback prematuro)
innobackupex --apply-log --redo-only /srv/mysql_backups/base/2023-11-15_09-00-00

# 2. Aplicar la primera incremental sobre la base
innobackupex --apply-log --redo-only /srv/mysql_backups/base/2023-11-15_09-00-00 --incremental-dir=/srv/mysql_backups/incr1/2023-11-15_12-00-00

# 3. Aplicar la segunda incremental (última fase, sin redo-only para hacer commit final)
innobackupex --apply-log /srv/mysql_backups/base/2023-11-15_09-00-00 --incremental-dir=/srv/mysql_backups/incr2/2023-11-15_15-00-00

Una vez que el directorio base ha incorporado todos los cambios incrementales y está en estado consistente, se procede con la restauración estándar usando --copy-back sobre el directorio base preparado.

innobackupex --copy-back /srv/mysql_backups/base/2023-11-15_09-00-00
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld

Es fundamental seguir el orden estricto de aplicación de logs: primero la base con --redo-only, luego cada incremental intermedia con --redo-only, y finalmente la última incremental sin --redo-only para permitir el rollback de transacciones pendientes y dejar los datos listos para producción.