Cómo migrar una base MySQL entre servidores sin pérdida de datos

Lista las bases y mide el tamaño real:

mysql -uroot -p -e "SELECT table_schema AS db, ROUND(SUM(data_length + index_length)/1024/1024, 2) AS size_mb FROM information_schema.tables GROUP BY table_schema;"

Anota el tamaño de la base que vas a migrar — lo necesitas para dimensionar el espacio en el destino y estimar el tiempo de dump (~1-2 minutos por GB en disco rápido).

Verifica qué engines están en uso:

mysql -uroot -p -e "SELECT table_schema, engine, COUNT(*) FROM information_schema.tables WHERE table_schema = 'mibase' GROUP BY table_schema, engine;"

Si aparece MyISAM en el resultado, considera convertirlas a InnoDB antes de migrar. MyISAM no soporta --single-transaction, forzando al dump a usar lock de tabla que bloquea escrituras.

Exporta los usuarios y permisos en un archivo separado:

mysql -uroot -p -e "SELECT CONCAT('SHOW GRANTS FOR ''', user, '''@''', host, ''';') FROM mysql.user WHERE user NOT IN ('mysql.sys','mysql.session','mysql.infoschema','root');" -s --skip-column-names | mysql -uroot -p -s --skip-column-names | sed 's/$/;/' > grants.sql

El dump estándar de mysqldump no trae los usuarios — viven en mysql.user, fuera de la base de la aplicación. Sin este archivo, restauras los datos pero las conexiones de la aplicación fallan con “Access denied”.

Genera el dump con flags de consistencia:

mysqldump -uroot -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --master-data=2 \
  --hex-blob \
  --default-character-set=utf8mb4 \
  mibase > mibase_$(date +%Y%m%d_%H%M%S).sql

Cada flag cubre un caso específico: --single-transaction garantiza snapshot consistente sin lock; --routines --triggers --events incluyen procedures, triggers y eventos programados; --master-data=2 graba la posición del binlog como comentario (útil para replicación posterior); --hex-blob evita corrupción de campos BLOB durante la transferencia.

Comprime el dump para acelerar la transferencia:

gzip -9 mibase_*.sql

La compresión gzip reduce dumps SQL en 70-85% típicamente. En bases grandes, esto transforma una transferencia de 40 minutos en 8 minutos — vale el tiempo de CPU.

Transfiere vía SCP desde el servidor de origen:

scp mibase_*.sql.gz [email protected]:/tmp/

Si la conexión es inestable o el archivo supera los 5 GB, prefiere rsync --partial --progress — reanuda desde donde se detuvo si se corta a la mitad.

En el servidor de destino, valida el checksum:

# En el origen:
sha256sum mibase_*.sql.gz

# En el destino:
sha256sum /tmp/mibase_*.sql.gz

Compara los hashes. Una diferencia significa corrupción en la transferencia — repite el SCP/rsync antes de restaurar. Restaurar un dump corrupto genera errores aleatorios a mitad del camino y exige rehacer todo.

Crea la base vacía con el charset correcto:

mysql -uroot -p -e "CREATE DATABASE mibase CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

El charset equivocado es fuente clásica de ”?????” en lugar de acentos. Si el origen usa utf8mb4, el destino tiene que usar utf8mb4 — no utf8 (que es de 3 bytes y rompe emoji).

Restaura el dump con flags de performance:

gunzip < /tmp/mibase_*.sql.gz | mysql -uroot -p \
  --max_allowed_packet=512M \
  --init-command="SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;" \
  mibase

Deshabilitar unique_checks y foreign_key_checks durante el restore acelera 3-5×. El dump es internamente consistente, así que no hay riesgo. Los checks vuelven al default en la próxima conexión.

Restaura usuarios y permisos:

mysql -uroot -p < grants.sql
mysql -uroot -p -e "FLUSH PRIVILEGES;"

FLUSH PRIVILEGES fuerza a MySQL a releer la tabla de permisos. Sin esto, algunos clientes siguen recibiendo “Access denied” incluso con los grants ya insertados.

Compara el conteo de filas tabla por tabla:

# En el origen:
mysql -uroot -p -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='mibase' ORDER BY table_name;" > origen_counts.txt

# En el destino:
mysql -uroot -p -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='mibase' ORDER BY table_name;" > destino_counts.txt

diff origen_counts.txt destino_counts.txt

table_rows en information_schema es una estimación para InnoDB — puede divergir levemente. Para conteo exacto en tablas críticas, ejecuta SELECT COUNT(*) FROM tabla en ambos lados.

Verifica objetos auxiliares:

mysql -uroot -p mibase -e "SHOW TRIGGERS\G SHOW PROCEDURE STATUS WHERE Db='mibase'\G SHOW EVENTS\G"

Triggers, procedures y eventos solo vienen en el dump si usaste las flags --triggers --routines --events. Si alguno está faltando, recolócalo manualmente vía dump específico (mysqldump --no-data --no-create-info --triggers ...).