Blog

Whitepaper técnico — PodHeitor MySQL / MariaDB para Bacula

Backup lógico paralelo, físico hot vía xtrabackup/mariabackup con cadena LSN incremental, MySQL 8.0.17+ CLONE INSTANCE agent-less, transportable tablespaces y provisioning DR de réplica nativo.

Documento técnico complementario a la página del plugin PodHeitor MySQL.

1. ¿Por qué no el plugin Bacula Enterprise MySQL?

El plugin Enterprise es Perl glue propietario alrededor de mysqldump / xtrabackup. Funciona, pero:

  • Requiere Perl runtime en cada host FD.
  • Jobs secuenciales per-database (sin paralelismo dentro de un job).
  • Documentadamente incompatible con la encriptación AES de volumen de Bacula al usar xtrabackup --prepare.
  • Sin provisioning DR de réplica, sin automatización TDE, sin CDP sidecar.
  • Closed source — no puedes auditar ni parchear lo que protege tu DB.
  • Pricing para budgets Fortune-500.

PodHeitor entrega el mismo feature set — y más — como un único binario Rust musl static-pie de ~540 KB, sin Perl, sin Python runtime.

2. Modelo arquitectural

Patrón PodHeitor: cdylib FD podheitor-mysql-fd.so (Rust puro, sin source AGPLv3 de Bacula linkeado) + backend standalone, comunicación PTCOMM en stdin/stdout.

Desde v2.0.0, el cdylib se construye desde ../PodHeitor Rust cdylib/crates/plugin-mysql/. Ningún source AGPLv3 de Bacula, headers, ni object files se vinculan estáticamente. El shim C++ legacy fue removido.

3. Modos de backup

Mode Función Engine usada
dump Logical dump per-DB con paralelismo (parallel_dbs) mysqldump / mariadb-dump
xtrabackup Physical hot backup con cadena LSN incremental xtrabackup (Percona)
mariabackup Physical hot backup MariaDB mariabackup
clone MySQL 8.0.17+ CLONE INSTANCE agent-less SQL nativo
replicate Provisioning DR — restore + setup automático de réplica SQL + CHANGE REPLICATION SOURCE

4. Topology awareness y safety gates

El plugin auto-detecta la topología MySQL y aplica safety gates configurables:

Topología detectada Detección Comportamiento
Standalone — Backup directo
Async-Replica SHOW REPLICA STATUS Backup del replica (offload del primary)
Group Replication performance_schema.replication_group_members Backup de miembro secundario; verifica lag
Galera wsrep_local_state Auto-desync donor con RAII guard

4.1 require_replica=true — safety gate

Bacula stock + xtrabackup típicamente hace backup del primary (porque es el nodo «default»). En una flota MySQL seria, eso es exactamente lo que no quieres — el primary ya está ocupado sirviendo writes. Setear require_replica=true hace que el plugin rechace el backup si el nodo conectado es primary. Combina con max_replica_lag=60 para evitar backup de réplicas atrasadas.

4.2 Galera donor RAII guard

En Galera, un nodo sacado para backup debe ser desincronizado del cluster (SET GLOBAL wsrep_desync=ON) para evitar que flow control afecte al cluster entero. El plugin lo hace con guard RAII: el flag es seteado antes del backup y garantizadamente removido incluso en panic/crash del backend, vía Drop trait.

5. Provisioning DR de réplica (modo replicate)

Validado en producción (JobId 3592). En el restore al host DR, el plugin ejecuta automáticamente:

STOP REPLICA;
RESET REPLICA ALL;
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.15.131',
  SOURCE_PORT=3306,
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='<from repl_password_file>',
  SOURCE_AUTO_POSITION=1;
START REPLICA;

Después verifica que ambas threads (Replica_IO_Running y Replica_SQL_Running) estén healthy antes de retornar success. Sin esto, «DR» significa restaurar el dump y operacionalmente recordar de configurar replicación — frecuentemente olvidado hasta el próximo incidente.

6. Features adicionales

Feature Status
Transportable tablespaces — single-table restore vía IMPORT TABLESPACE Production
TDE keyring export + re-install on restore Production
CDP binlog streamer sidecar — mysqlbinlog --stop-never --raw + systemd unit Production
Prometheus textfile-collector metrics Production
Post-restore verify (basic/checksum/deep) Production
Streaming PTCOMM — cero staging area, compatibilidad con encryption nativa Bacula Production

El documento docs/ENTERPRISE_PARITY.md mapea 48 de 48 features del Bacula Enterprise MySQL Plugin 18.2.3 que están atendidas o superadas.

7. Matriz de soporte validada

Engine Versiones Mode coverage
MySQL Community / Enterprise 5.7 EOL · 8.0 ≥ 8.0.17 · 8.4 LTS dump, xtrabackup, clone, replicate
Percona Server 8.0.x dump, xtrabackup, clone, replicate (+ TDE keyring)
MariaDB 10.5 · 10.6 LTS · 10.11 LTS · 11.4 LTS dump, mariabackup, replicate

OS: Oracle Linux 9 / RHEL 9 / Rocky 9 / AlmaLinux 9, EL8 (rebuild), Debian 12, Ubuntu 22.04/24.04. Bacula: Community 15.0.3.

8. Anti-patterns documentados

  • No combines la encriptación AES de volumen Bacula con xtrabackup --prepare sin probar restore end-to-end. La documentación Enterprise reconoce la incompatibilidad; PodHeitor sintetiza el prepare durante el restore para evitar este modo problemático.
  • No corras require_replica=false en producción sin entender que esto permite backup del primary — puede ser intencional, pero es la fuente más común de «el backup se puso lento y borró mi p99 latency».
  • No confíes en parallel_dbs alto sin ajustar I/O del host. 4 dumps paralelos de DBs grandes saturan disco antes que CPU. Comienza en 4, monitorea iostat.

9. Postura de licencia

Plugin bajo LicenseRef-PodHeitor-Proprietary. Source AGPLv3 de Bacula no se vincula estáticamente desde v2.0.0. El shim C++ legacy src/podheitor-mysql-fd.{c,h} fue removido. Bindings vía crate bacula-fd-abi independiente.

¿Listo para evaluar?

Trial comercial de 30 días para flotas MySQL/MariaDB/Percona en producción. Garantizamos al menos 50% de descuento vs Bacula Enterprise, Veeam o Commvault, con más funcionalidades incluidas.

Heitor Faria — Fundador, PodHeitor International
✉ [email protected]
☎ +1 (789) 726-1749 · +55 (61) 98268-4220 (WhatsApp)
🔗 Página del plugin PodHeitor MySQL

Disponível em: pt-brPortuguês (Portugués, Brasil)enEnglish (Inglés)esEspañol

Deja una respuesta