Se você trabalha com bancos de dados, um dia acabará vivenciando aqueles famosos problemas que se tornam uma história a ser contada. As famosas histórias de guerra — daquelas que fazem um DBA suar frio e o MySQL tremer na base.
E, a seguir, vamos mencionar uma delas.
🕗 Dezembro… o mês mais aguardado para pessoas normais e o mais temido para aqueles que são DBA’s.
Numa certa manhã, havíamos recebido um alarme comum de atraso no sincronismo entre uma base PRIMARY e REPLICA. E assim, como padrão, fizemos os levantamentos do que justificaria esse atraso.
Notamos um comando peculiar sendo replicado via System User:
➡️ DELETE FROM name_table WHERE column_date >= ‘2025-11-28 00:00:00’.
Um comando aparentemente simples, mas executado sem um limite de escopo temporal adequado.
Assim, em contato com a gestão da aplicação, explicamos o tal “problema” e, via logs, exibimos os comandos executados.
Contexto desta execução: “Entre os dias 28/11 e 01/12 não havia necessidade de certos dados…, mas o complemento do filtro não deve ter funcionado.” 😨😨😨
🧙🏻♂️ Então… os MAGOS da DBAOnline entraram em ação para a restauração dos dados deletados. 🧙🏻♂️
Fizemos a restauração do backup completo (Full), realizado no dia 27/11, concluído às 03 horas da manhã, em uma base de Homologação.
Partimos para a restauração e, após a conclusão dessa primeira etapa, precisaríamos restaurar os BINLOGS da máquina produtiva até chegarmos exatamente uma posição anterior à deleção dos dados.
Então, iniciamos a aplicação dos binlogs da máquina PRIMARY diretamente nessa base de Homologação (que continha a restauração de um backup feito na base REPLICA).
Foram praticamente 6 binlogs restaurados.
Agora… para animar aquela noite/madrugada, os 3 últimos binlogs tinham que relatar problemas.
O backup feito na base REPLICA não possuía 10 tabelas que, por regras, não replicamos através do ambiente PRIMARY, devido ao uso da variável “replicate-ignore-table”. Assim, os binlogs da PRIMARY possuíam instruções para essas tabelas. Não podíamos simplesmente criá-las no ambiente de Homologação, pois as instruções contidas no binlog eram operações de deleção ou update — e, em uma tabela sem registros, haveria erros.
Então, seguimos com o comando:
➡️
|
1 2 3 4 5 |
mysqlbinlog --exclude-gtids='gtid_number' --verbose --base64-output=DECODE-ROWS /dir/do/binlog | awk '/Table_map:/ {if (match($0, "´databaseName´, ´table_condition´*") {skip=1; next} else {skip=0; print; next}} skip && (/Write_rows:/ || /Update_rows:/ || /Delete_rows:/) {next} {print}' | mysql -u user -p |
E, para finalizar corretamente a uma posição antes do comando executado (delete), utilizamos o mesmo contexto adicionando somente a condição stop-datetime:
➡️
|
1 2 3 4 5 6 |
mysqlbinlog --exclude-gtids='gtid_number' --verbose --base64-output=DECODE-ROWS /dir/do/binlog --stop-datetime="2025-12-03 07:50:00" | awk '/Table_map:/ {if (match($0, "´databaseName´, ´table_condition´*") {skip=1; next} else {skip=0; print; next}} skip && (/Write_rows:/ || /Update_rows:/ || /Delete_rows:/) {next} {print}' | mysql -u user -p |
Obviamente, a cada aplicação de binlog efetuada na base de Homologação, definíamos uma tabela no sistema e realizávamos o COUNT em períodos de datas para comparações. Ao final do processo, as validações foram realizadas com sucesso; os dados necessários a serem retomados estavam na máquina de Homologação.
🔍 Lições aprendidas nesta batalha.
Essa história deixou 4 mensagens importantes — tanto para o time DBAOnline quanto para qualquer empresa que utiliza o MySQL:
-
BACKUP não é opcional… é obrigatório.
Se não tivéssemos backups a serem restaurados, não teríamos esta história.
E “backup só é backup depois que é restaurado”. -
BINLOGS são os salva-vidas.
Sem binlogs, o cliente teria perdido horas de dados.
Até porque, não adianta backup sem binlogs — o RPO vai para o espaço. -
Acidentes acontecem — processos evitam desastres.
Testes e validações antes são sempre importantes numa execução; revisão de permissões para cada usuário. -
Ter um time especializado muda o desfecho.
MySQL exige um conhecimento profundo de arquitetura, recovery e consistência.
🧨 Desfecho — Toda guerra deixa algumas experiências.
A DBAOnline voltou para casa naquele dia mais experiente, com mais reforços nos processos e com a certeza de que:
“No campo de batalha dos dados, não vence quem nunca erra — vence quem sabe se levantar rapidamente”.
Referências:
https://www.dbaonline.com.br/
