Como migrar banco MySQL entre servidores sem perda de dados

Liste os bancos e meça o tamanho 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;"

Anote o tamanho do banco que você vai migrar — você precisa disso pra dimensionar o espaço no destino e estimar o tempo de dump (~1-2 minutos por GB em disco rápido).

Verifique quais engines estão em uso:

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

Se aparecer MyISAM no resultado, considere converter pra InnoDB antes de migrar. MyISAM não suporta --single-transaction, forçando o dump a usar lock de tabela que bloqueia escritas.

Exporte os usuários e permissões em arquivo 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

O dump padrão do mysqldump não traz os usuários — eles vivem em mysql.user, fora do banco da aplicação. Sem esse arquivo, você restaura os dados mas as conexões da aplicação falham com “Access denied”.

Gere o dump com flags de consistência:

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

Cada flag cobre um caso específico: --single-transaction garante snapshot consistente sem lock; --routines --triggers --events incluem procedures, triggers e eventos agendados; --master-data=2 grava a posição do binlog como comentário (útil pra replicação posterior); --hex-blob evita corrupção de campos BLOB durante a transferência.

Compacte o dump pra acelerar a transferência:

gzip -9 meubanco_*.sql

Compressão gzip reduz dumps SQL em 70-85% tipicamente. Em bancos grandes, isso transforma uma transferência de 40 minutos em 8 minutos — vale o tempo de CPU.

Transfira via SCP do servidor de origem:

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

Se a conexão é instável ou o arquivo passa de 5 GB, prefira rsync --partial --progress — ele retoma de onde parou se cair no meio.

No servidor de destino, valide o checksum:

# No origem:
sha256sum meubanco_*.sql.gz

# No destino:
sha256sum /tmp/meubanco_*.sql.gz

Compare os hashes. Diferença significa corrupção na transferência — repita o SCP/rsync antes de restaurar. Restaurar dump corrompido gera erros aleatórios meio do caminho e exige refazer tudo.

Crie o banco vazio com charset correto:

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

Charset errado é fonte clássica de ”?????” no lugar de acentos. Se o origem usa utf8mb4, o destino tem que usar utf8mb4 — não utf8 (que é 3 bytes e quebra emoji).

Restaure o dump com flags de performance:

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

Desabilitar unique_checks e foreign_key_checks durante o restore acelera em 3-5×. O dump é internamente consistente, então não há risco. Os checks voltam ao default na próxima conexão.

Restaure usuários e permissões:

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

FLUSH PRIVILEGES força o MySQL a reler a tabela de permissões. Sem isso, alguns clientes continuam recebendo “Access denied” mesmo com os grants já inseridos.

Compare contagem de linhas tabela por tabela:

# No origem:
mysql -uroot -p -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='meubanco' ORDER BY table_name;" > origem_counts.txt

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

diff origem_counts.txt destino_counts.txt

table_rows em information_schema é estimativa pra InnoDB — pode divergir levemente. Pra contagem exata em tabelas críticas, rode SELECT COUNT(*) FROM tabela em ambos os lados.

Verifique objetos auxiliares:

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

Triggers, procedures e eventos só vêm no dump se você usou as flags --triggers --routines --events. Se algum estiver faltando, recoloque manualmente via dump específico (mysqldump --no-data --no-create-info --triggers ...).