Mysql Backup Full e Incremental

Fala ai rapeeeeize, coméquiseistão?

Eu vou muito bem, obrigado por perguntarem (Mentiram, ninguém perguntou).

Eu ando perdendo algumas noites de sono e alguns dias de trabalho estudando a melhor maneira de criar um sistema de backup eficiente para um sistema de larga escala e assim poder dormir em paz novamente.

Tava lendo sobre um tal de mysql bin-logs, já ouviram falar disso? É uma parada que cria um log de tudo o que rola no seu BD (Se estiver habilitado, né, migo?), desde um simples insert até um DELETE * FROM notas_fiscais; (True history).

Por padrones (Leia-se: Padrão) algumas distro linux vem com esse esquemásso desabilitado, mas para habilitar é simplão, só abrir seu arquivo de configuração do MySQL/MariaDB e adicionar essas linhas:

Na primeira linha, o parâmetro log_bin, nós definimos a pasta onde os nossos binlogs serão salvos e, o parâmetro expire_logs_days é o parâmetro que determina quanto tempo o sistema deve manter esses binlogs lá, tranquilões.

Salvando esse arquivo e dando aquela reiniciada no nosso server mysql, conseguimos rodar o comando “ls -l /var/lib/mysql/mysql-bin.*” que já vamos ver nosso bin-log lá, lindão e pleno como ele deve ser.

Pra você ter ideia de como esse código é cabuloso, a gente consegue quebrar o os bin-logs em vários arquivos, porém, apenas 1 arquivo é ativo no momento, para ver qual está ativo no momento, abra seu terminal e rode: mysql -u seuusuario -e ‘SHOW MASTER STATUS;’

Você vai ver algo parecido com isso

Agora, como eu sempre digo para meus colegas programadores:

Vamos criar um novo Banco de Dados para exemplificar o uso dos binlogs:

Nossa linda tabela criada, vamos inserir alguns dados:

Feito tudo isso, temos o quê? Um banco de dados LINDO, parecido com isso:

Pronto, nosso banco de dados está criado, os clientes estão inserindo seus dados e a gente configura um pequeno cronjobzinho para realizar um backup de hora em hora com o famoso mysqldump: “mysqldump -u root -p teste — single-transaction — flush-logs > backup_completo.sql”

A flag — singles-transaction vai fazer com que seu dump seja feito corretíssimo e caso alguma entrada falhe, você vai receber a mensagem: “Perdeu playboy“ (Mentira, ele vai fazer com que você não faça nenhuma cagada no banco de dados, descartando qualquer alteração), e a — flush-logs vai fazer com que o arquivo bin-log atual seja fechado e vai abrir um novo, lindo e pleno, tanto que depois desse comando, se a gente rodar um “SHOW MASTER STATUS;” olha o resultado:

Reparou no “000002”?

Agora vamos adicionar mais algumas coisas no nosso banco de dados, afinal, os clientes estão usando, não é mesmo?

Vamos ver como ficou nosso banco de dados depois de tudo isso?

Lindo, né?

Agora, como inserimos mais dados, vamos criar um novo bin-log com: “mysqladmin -u root -p flush-logs”.

Mas, nem tudo são flores, não é mesmo? Seria uma pena se…

Uma pena, não? Não!!!!! Você fez um backup, lembra??? Vamos subí-lo?

E após rodar:

Nessa hora seu chefe / gerente / amigo gela, cadê os dados entre um backup e outro??? Fudeu??? NÃO! Você ainda tem os bin-logs, lembra?? Vamos subí-lo?

Feito isso, vamos ver como está nosso BD?

Sucesso, nossos dados estão todos lá!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.