Gerador de Comando mysqldump

mysqldump em profundidade: backup consistente, streaming e estratégia de restore

O mysqldump é o utilitário canônico de backup lógico que vem com MySQL e MariaDB. Lógico significa que ele produz um script SQL puro — uma sequência de CREATE TABLE, INSERT e, opcionalmente, definições de rotinas — que qualquer servidor compatível consegue replicar. A forma geral é mysqldump [options] db_name [tabelas] > out.sql. É portável, legível, fácil de grepar e funciona entre versões maiores; também é single-threaded e fica lento em datasets de muitos terabytes, motivo pelo qual times em produção acabam juntando com ferramentas de backup físico como Percona XtraBackup ou mydumper.

Flags de conexão e seleção

• -u user — usuário; -p pede a senha (nunca coloque inline no histórico de shell).
• -h host, -P porta — alvo remoto.
• --all-databases — todos os schemas, inclusive tabelas de sistema.
• --databases db1 db2 — vários schemas específicos (inclui CREATE DATABASE).
• db_name tab1 tab2 — um schema, tabelas específicas.
• --ignore-table=db.tabela — exclui uma ou mais tabelas (repetível).

Consistência: as flags que importam em produção

Um mysqldump ingênuo contra um servidor ativo pode gerar snapshot inconsistente ou travar gravações durante toda a execução. As flags críticas são:

--single-transaction   InnoDB: faz dump dentro de uma tx REPEATABLE READ,
                       sem locks, snapshot consistente. Obrigatória
                       em qualquer base InnoDB em produção.
--lock-tables          MyISAM/Aria: trava cada DB enquanto dumpa.
--master-data=2        Escreve a posição do binlog/GTID como comentário
                       (útil para subir replica a partir do dump).
--set-gtid-purged=ON   Emite SET @@GLOBAL.GTID_PURGED na saída;
                       use OFF ao restaurar em um universo GTID novo.
--flush-logs           Faz rotate do binlog antes do dump.
--quick                Streama linhas em vez de bufferar em RAM
                       (padrão em versões modernas, inofensivo).

Regra geral: em InnoDB use --single-transaction --quick --routines --triggers --events. Em MyISAM ou bases com engines misturadas, use --lock-tables (e aceite a pausa de gravações).

Só schema, só dados e ajustes de formato

• --no-data — só estrutura (base de migração de schema).
• --no-create-info — só dados (refresh de tabelas já existentes).
• --routines — inclui stored procedures e funções.
• --triggers — inclui triggers (ligado por padrão).
• --events — inclui eventos agendados.
• --add-drop-database, --add-drop-table — emite DROP IF EXISTS antes do CREATE.
• --default-character-set=utf8mb4 — evita mojibake; combine com o da base ativa.
• --hex-blob — codifica binário como literal hexa (mais seguro para blobs).
• --compress — comprime o protocolo na rede (ajuda em WAN).

Exemplos comentados

# Dump padrão production-safe, com gzip no fluxo
mysqldump -u backup -p \
  --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 \
  mydb | gzip > mydb-$(date +%F).sql.gz

# Stream direto para S3 sem arquivo local
mysqldump -u backup -p --single-transaction mydb \
  | gzip | aws s3 cp - s3://backups/mydb.sql.gz

# Só schema, pronto para semear um ambiente de staging
mysqldump -u root -p --no-data mydb > schema.sql

# Restore: simplesmente despeja o SQL de volta no mysql
gunzip < mydb.sql.gz | mysql -u root -p mydb

# Retoma replicação a partir da posição registrada
mysqldump --master-data=2 --single-transaction --all-databases > full.sql

Performance, criptografia e variantes em nuvem

O mysqldump é single-threaded; para centenas de gigabytes considere o mydumper (dump lógico paralelo, restore mais rápido via myloader), o Percona XtraBackup (backup físico a quente, única escolha sã na faixa de muitos terabytes) ou o MySQL Enterprise Backup. Sempre criptografe backups em repouso — canalize a saída por openssl enc -aes-256-cbc ou gpg, ou confie na camada de armazenamento (S3 com KMS, volumes LUKS).

Serviços gerenciados embrulham equivalentes: AWS RDS com snapshots automáticos e logical exports sob demanda, Azure Database for MySQL com backups, GCP Cloud SQL com export para bucket. Por baixo ainda chamam mysqldump ou um snapshot binário — conhecer as flags ajuda a raciocinar sobre as garantias de consistência.

FAQ

Dá para fazer backup a quente sem travar gravações? Sim — em InnoDB, --single-transaction abre um snapshot REPEATABLE READ consistente e deixa as gravações seguirem. Qualquer DDL durante o dump (ALTER TABLE, CREATE TABLE) quebra a garantia de consistência.

Como dumpar uma única tabela? mysqldump db_name tabela > t.sql — liste as tabelas após o nome do banco. Combine com --where='id>1000' para dumpar um subconjunto de linhas.

Dá para fazer restore parcial de um dump grande? SQL puro é grepável: sed -n '/^-- Table structure for table .users.$/,/^-- Table structure/p' dump.sql. Para restores parciais rotineiros, prefira gerar dumps por tabela desde o início.

Quanto demora um restore? Regra de bolso: um dump SQL puro de 10 GB restaura em uns 30–60 min em SSD, gargalado pelo replay de INSERT single-threaded. Acelere desligando checks de FK (SET FOREIGN_KEY_CHECKS=0; no topo), aumentando innodb_buffer_pool_size e usando --extended-insert.

O dump é portável entre versões? Sim, com ressalvas. O mysqldump 8 lê servidores 5.7, e um dump do 5.7 geralmente carrega no 8 (cuidado com palavras reservadas e mudança de plugin de autenticação). Restaurar dump do 8.0 no 5.7 pode falhar em sintaxe como cláusulas WINDOW.