Como fazer backup de bancos mysql GIGANTES

Um banco de dados que era acostumado a lidar e gostava de seu esquema de backup era o SQL Server, ele exporta um único arquivo e importa de forma extremamente rápida, mesmo para bancos muito grandes porque praticamente é uma transferência de arquivos de uma máquina para outra, porém com o mysql as coisas ainda podem parecer um pouco pré-históricas, mas vou deixar aqui algumas dicas importantes pra você que pretende fazer o processo de backup/importação de bancos de dados muito grandes no mysql:

Esses dias me deparei com a necessidade de restaurar meus bancos de dados por conta de erros, provavelmente por conta de arquivos corrompidos e descobri que posso copiar a pasta do banco de dados, porém existem grandes ressalvas.

Os bancos de dados ficam localizados em mysql/data, no caso do xampp “C:\xampp\mysql\data”, esse processo de copiar as pastas do banco de dados é intitulada como “Cold Backup” ou “Cópia Física”, é muito mais rápido para bancos gigantes do que exportar arquivos .sql (cópia lógica), mas para funcionar entre servidores diferentes, você precisa seguir estas regras:

1. A Regra de Ouro: O ibdata1

No MySQL/MariaDB (usando o motor InnoDB, que é o padrão), os dados não ficam apenas dentro da pasta com o nome do seu banco. O arquivo ibdata1 (que fica na raiz da pasta data) guarda o “dicionário de dados” e os metadados de todas as tabelas InnoDB.

• Para funcionar: Você não pode copiar apenas a pasta do banco (ex: /meu_banco_gigante/). Você precisa copiar a pasta do banco E o arquivo ibdata1 do servidor de origem para o de destino.
• O risco: Se o servidor de destino já tiver outros bancos de dados, ao substituir o ibdata1 dele pelo seu, você apagará o acesso aos bancos que já existiam lá.

 

2. Versões do Servidor

O servidor de origem e o de destino devem ser, preferencialmente, da mesma versão (ou o destino ser uma versão levemente superior). Mover arquivos físicos do MariaDB 11 para um MySQL 5.7, por exemplo, certamente causará erros graves de compatibilidade.

3. O estado dos serviços

Nunca copie os arquivos com o MySQL/MariaDB rodando. Os dados podem estar em cache e não terem sido gravados no disco ainda, o que causaria corrupção (como o erro de checksum que você acabou de ter).

• Pare o serviço nos dois servidores antes da cópia.

 

Alternativa para Bancos Gigantes (Sem apagar o destino)

Se você precisa mover um banco enorme para um servidor que já tem outros dados e não pode sobrescrever o ibdata1, o melhor caminho é usar o MySQL Workbench ou o comando mysqldump via terminal, que é muito mais robusto que o phpMyAdmin para arquivos grandes.
O comando via terminal seria:

bash
mysqldump -u root -p nome_do_banco > backup.sql

Use o código com cuidado.
Para importar:

bash
mysql -u root -p nome_do_banco < backup.sql

Alternativas Mais Fortes

Se você esta lidando com banco de dados realmente grandes o mysqldump pode ser lento lento porque ele reconstrói o banco linha por linha (comandos INSERT), o que gera um estresse enorme de I/O e processamento.
Se você trabalha com bancos realmente grandes e quer algo próximo da performance e praticidade do SQL Server, existem três caminhos “profissionais” para o MySQL/MariaDB:

1. Transportable Tablespaces (O “.bak” do MySQL)

Desde as versões mais recentes (MySQL 5.6+ / MariaDB 10.x), você pode “destacar” uma tabela ou banco e movê-lo sem precisar do ibdata1 completo.

• No servidor de origem, você executa: FLUSH TABLES nome_tabela FOR EXPORT;
• Isso gera um arquivo .cfg. Você copia o .ibd (dados) e o .cfg para o novo servidor.
• No destino, você usa: ALTER TABLE nome_tabela IMPORT TABLESPACE;
• Vantagem: É velocidade de cópia de arquivo (disco para disco), quase instantâneo.

2. Mydumper / Myloader (O “Dump” Multi-thread)

O mysqldump é monothread (usa um núcleo só). O Mydumper é uma ferramenta de terceiros (muito usada em ambientes Linux/Produção) que faz o backup de forma paralela.

• Ele divide o banco em vários arquivos e usa todos os núcleos do processador para exportar e importar.
• A velocidade de restauração chega a ser 10x superior ao mysqldump tradicional.

3. Percona XtraBackup (O padrão para bancos Gigantes)

Se você lida com servidores Linux, essa é a ferramenta definitiva. Ela faz o que chamamos de “Hot Backup”.

• Ele copia os arquivos físicos enquanto o banco está rodando, sem travar nada.
• Para restaurar, basta mover a pasta para o novo servidor e dar um comando de “prepare”.
• É o que chega mais próximo da experiência de mover um banco de dados de alta disponibilidade.

4. Dica de Ouro para o mysqldump

Se você for obrigado a usar o dump comum, adicione esses parâmetros para acelerar a importação (que é onde costuma demorar mais):

bash
--disable-keys --no-autocommit --single-transaction

Use o código com cuidado.
Isso faz o MySQL parar de checar índices a cada linha e só gravar tudo no final, o que ganha muito tempo.