Usando o mysqlbinlog para refazer o banco de dados

Ah os backups...
Por mais que você se esforce para mantê-los em dia e para não precisar deles, você vai precisar e, justo neste dia você vai descobrir que quem tem uma fonte de backup apenas, não tem nenhuma e se tiver duas fontes, periga não ter nenhuma do mesmo jeito.
Caso os seus backups do banco de dados mysql estiverem comprometidos, mas consiga ter acesso aos logs binários, pode existir uma luz no fim do túnel. É possível refazer o banco totalmente, ou em partes, a partir destes arquivos que são uma verdadeira mão na roda.
Os arquivos binários do servidor mysql são arquivos que contém a descrição das modificações ocorridas dentro de um banco de dados. O servidor grava estes arquivos no formato binário, então, não basta apenas abrir o arquivo para poder compreender o que ocorre dentro dele.
O MySQL possui um programa chamado mysqlbinlog que permite converter estes arquivos para o formato texto e, a partir dai, pode-se usar as informações gravadas nestes arquivos para os mais diversos fins, que vão desde uma auditoria no banco para descobrir quem fez o que e quando, até mesmo a recuperação de todo o banco de dados após a corrupção de suas tabelas.
Em distribuições linux, os arquivos binários geralmente se encontram em /var/log/mysql. Nesta pasta serão encontrados arquivos numerados sequencialmente no seguinte formato mysql-bin.000233.
O acesso a estes arquivos pode se dar remotamente, mas em geral, opta-se pelo acesso direto à pasta onde estão os arquivos. Daremos continuidade, partindo deste pressuposto.
A abordagem mais usada é a de gerar arquivos texto a partir dos arquivos binários e aplicar este arquivo texto ao banco de dados:
mysqlbinlog mysql-bin-000233 > /tmp/arquivo.txt.
Outro ponto importante com relação ao log binário: a cada vez que o servidor MySQL é reiniciado, um novo arquivo é gerado. Portanto, os dados que se queira reparar podem estar espalhados em diversos arquivos. Neste caso, pode-se usar os recursos do shell script para direcionar a saída de vários arquivos de log para um único arquivo de texto. Supondo que as informações que queiramos estejam nos arquivos mysql-bin.000233 a mysql-bin.000245, podemos fazer da seguinte forma:
for i in $( seq 233 245 ) ; do mysqlbinlog mysql-bin.$(printf "%06d" $i) >> /tmp/saida.txt ; done
Este laço executa o mysqlbinlog em cima de todos os arquivos que tenham numeração entre 233 e 245 e direcionam o resultado para o arquivo saida.txt.
Pode se agora fazer com que os comandos armazenados em saida.txt sejam executados no seu servidor de banco de dados:
mysql -h seuHost -u seuUsuario seuBancoDados - p
Feito isto todas os comandos que foram armazenados nos logs binarios redirecionados para o arquivo saida.txt serão executados no banco de dados seuBancoDados.
Cuidados Importantes:

• O mysqlbinlog armazena informações de todos os bancos de dados gerenciados pelo servidor. Caso se queira recuperar informações de apenas um banco de dados, deve-se indicar explicitamente qual das bases se deseja trabalhar.
• O mysqlbinlog armazena informações sobre o momento em que as alterações ocorreram no banco de dados e é possível indicar este momento a partir de parâmetros passados ao mysqlbinlog. Ter isto em mente ajuda a uma recuperação mais consistente e segura.
• LEIA O MANUAL antes de aplicar as idéias deste POST. Perca 5 minutos entendendo o que é possível fazer com este aplicativo tão útil do MySQL. Caso consiga melhorar esta minha idéia, ficarei agradecido se postar a solução aqui como comentário.
  

Mais uma de svn

A nomenclatura dos comandos do svn pode enganar um pouco.
O comando revert, por exemplo, cujo nome dá a ideia de que se possa reverter a uma versão anterior, na verdade apenas auxilia na resolução de conflitos, revertendo qualquer alteração feita nos arquivos locais. Além de reverter o conteúdo de um determinado item da cópia de trabalho, altera também qualquer propriedade alterada.
Quando se quiser reverter uma cópia de trabalho para versões anteriores deve-se usar o comando merge. O svn merge verifica e aplica as mudanças existentes na cópia de trabalho entre duas versões diferentes do projeto. Uma forma genérica de aplicar o comando:

svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]

svn merge -r N:M SOURCE [PATH]

Na primeira forma a URL da fonte é especificada nas revisões N e M. Indicando as duas fontes que se queira comparar.

Na segunda forma, a fonte pode ser uma URL ou uma cópia de trabalho, neste caso a URL correspondente é usada.

Num exemplo mais prático:

svn merge -rhead:689 http://my/svn/repository ./workingcopy

Onde a indicaçao de head indica a ultima versão no repositório e 689 indoca qual a versão a qual se deseja retornar.

Versoes conflitantes de projetos no SVN

O SVN é, sem duvida, um dos aplicativos para controle de versão mais bacanas que eu conheço.
Salva a vida de qualquer desenvolvedor, principalmente quando se tem muita gente trabalhando em projetos grandes (mas não só nestes casos). E acredite, já sofri muito tendo que controlar versões de sistemas "na unha".
Mas, quando as equipes são grandes, as vezes espalhadas cada qual em seu cantinho (do seu lado ou a quilometros de distancia) e não raramente usando os mais diferentes sistemas operacionais, pode surgir um pequeno problema: a versao do SVN do servidor onde está o repositório é diferente da versão do cliente do desenvolvedor.
Quando isto ocorre, obtem-se mensagens como: "Este cliente é muito velho para trablhar com a cópia de trabalho".
Há uns 4 meses atrás, tive este problema e, depois de algumas horas no google, encontrei a solução. Trata-se de uma pequena aplicação desenvolvida em python que convertia a versão do projeto para uma versão compatível com a do servidor.
O uso e bem simples: python change-svn-wc-format.py CAMINHO_DO_PROJETO versao_do_svn. Desta forma é feito o "Downgrade" de seu projeto, sem qualquer tipo de perda. Assim, rápido e fácil.
Para obter uma cópia do aplicativo: change-svn-wc-format.py

Voce sempre perde suas solucoes?

Eu perco...
E fico P... da vida comigo mesmo porque geralmente eu documento em algum lugar, que nunca sei onde e:
Ta num arquivo na pendrive?
Ta em alguma pasta do notebook com um nome nada a ver?
Ta no computador do trabalho?
Num arquivo do googledocs?
Num e-mail que mandei pra mim mesmo?
Ta num bloquinho de notas em cima da escrivaninha la de casa?
Pra tentar sanar este problema (ou acrescentar mais um item na minha lista de lugares pra procurar) resolvi criar este blog e me forçar a colocar aqui as soluções praqueles problemas que na hora sao tao urgentes, mas depois de passado algum tempo, nem sem mais por onde passa.
Por que Cafe Insoluvel?
Ah, eu adoro cafe e problemas (que parecem) sem solucao.