Como versionar banco de dados MySQL

Como versionar banco de dados MySQL

9 de maio de 2019 0 Por Ramos de Souza Janones
Powered by Rock Convert

Como realizar o versionamento de bancos de dados MySQL das mudanças que chegam de dois lados: no ambiente de desenvolvimento, produção, e homologação.

 

Uma grande dificuldade em se trabalhar com bancos de dados é que as mudanças chegam de dois lados: alterações de dados ocorrendo no ambiente de produção, e alterações de estrutura seguindo o processo “normal” (desenvolvimento, testes, qualidade, produção – ou seja qual for a progressão de ambientes que você/sua empresa use).

Ambas têm que ocorrer em harmonia.

Alterações de Dados

Existe pouca razão para se versionar as alterações de dados, mas se necessário isso pode ser feito simplesmente fazendo um dump ou backup dos mesmos, e versionando essas cópias da maneira que achar melhor (talvez até o próprio git). É importante, claro, que ao se restaurar essas cópias a estrutura do banco esteja tal qual estava quando a cópia foi feita, mas isso se torna simples quando se mantém no próprio BD um registro das alterações de estrutura (mais sobre isso adiante).

Alterações de Estrutura

Irreversibilidade

Seja qual for o método usado para se alterar a estrutura do BD (execução de um script sql, instalação de componentes externos), essa alteração somente pode ser feita uma vez, e não pode ser desfeita. Claro, você pode executar o mesmo script duas vezes e o resultado final ser o mesmo, ou você pode executar um script que traz o BD a um estado idêntico ao anterior, mas ainda assim isso conta como duas alterações (principalmente se algo sair errado).

Dada a irreversibilidade das alterações de estrutura, é importante se manter um registro de quais alterações já foram aplicadas a um BD específico, e se uma dada alteração já foi feita, não fazê-la de novo. Uma maneira é manter no próprio BD uma tabela listando quais alterações foram realizadas, e em qual ordem.

Leia também:  

Testes, testes, testes…

Se uma alteração feita, digamos, no ambiente de desenvolvimento, falhou no ambiente de testes, não se deve simplesmente alterar o ambiente de testes e seguir em frente. Pelo contrário, deve-se restaurar ambos ambientes para o estado anterior à alteração (ainda que isso signifique destruir o BD e restaurá-lo a partir de um backup) e criar uma nova alteração para substituir aquela que não deu certo (descartando-a). Se dessa vez funcionou em testes mas falhou na qualidade, começa tudo de novo…

Isso garante que, uma vez que as alterações estiverem prontas para serem aplicadas ao ambiente de produção, as mesmas já tenham sido testadas múltiplas vezes em diferentes circunstâncias, com diferentes conjuntos de dados pré-existentes.

Leia também: Release do livro: Desenvolvedor Kotlin Android – Bibliotecas para o dia a dia

(e, respondendo diretamente ao seu caso particular, não creio que seja uma boa ideia copiar o estado do ambiente de homologação para a produção – conclusão que você próprio também tirou; o ideal seria aplicar as mesmas ações – execução de scripts, instalação de componentes – realizadas em um ambiente no ambiente seguinte, na mesma ordem, naturalmente precedido de um backup completo do banco)

Curso completo de Games, inclusive Realidade Aumentada.Powered by Rock Convert

Migração de Dados

Com frequência os dados precisam ser ajustados em decorrência de uma alteração – colocar valores padrão para uma coluna recém-criada, mover dados e uma tabela pra outra, converter de um formato para outro, etc. Como isso é algo que afeta todos os dados do BD – seja em que estado eles estiverem – e também só é feito uma vez, pode-se tratar esse tipo de alteração como uma mudança de estrutura normal – versionando-a e testando-a de ambiente a ambiente.

Isso pode ser feito em um único script sql ou, dependendo das particularidades de sua ferramenta (o django-south por exemplo diferencia entre migração de esquema e migração de dados), em múltiplas etapas. Exemplo:

  1. Criar uma nova coluna nullable, e marcar uma já existente também como nullable;
  2. Mover todos os dados da coluna antiga para a nova, convertendo o formato se necessário;
    • Opcional: testar sua camada de aplicação nesse estado;
  3. Marcar a coluna nova como não-nullable, e destruir a coluna antiga.

Restaurando a um Estado Anterior

Finalizando, se por qualquer razão for necessário restaurar os dados arquivados no passado, tudo o que você precisa fazer é:

  1. Verificar na sua cópia qual era o estado do banco no momento em que ela foi feita (simples, pois o conjunto de alterações que o BD sofreu estavam registradas em uma tabela, e isso foi salvo junto com os demais dados);
  2. Verificar se o banco atual está ou não no mesmo estado (i.e. mesmo conjunto de alterações, mesma ordem); se sim, basta restaurar os dados.
  3. Se o banco está em um estado anterior, basta realizar no mesmo as alterações pendentes até que ele atinja o estado apropriado para restaurar a cópia.
  4. Se, por outro lado, ele está num estado posterior, então é necessário colocar esses dados em um novo banco provisório, aplicar as alterações necessárias para trazê-lo ao estado desejado, e então transferir os dados pro banco definitivo.

Desnecessário dizer, o código da aplicação a ser utilizado deve estar numa mesma versão que dá suporte ao banco em seu estado desejado. Assumindo que você salvou os scripts de alteração no controle de versões, isso consiste em verificar qual a última versão estável que contém aquele conjunto de alterações, e nenhuma mais nova.

Nota: essa resposta se baseou em parte no artigo (em inglês) “Database Changes Done Right” e no modo de funcionamento da ferramenta de migração de esquema django-south, além da minha experiência pessoal.

Outra Sugestão

É o uso do Liquibase (http://www.liquibase.org/).

Ele organiza toda a evolução do banco de dados.

Por exemplo: Quando eu crio uma tabela eu coloco o .sql de criação no liquibase e executo ele. Com isso ele vai rodar o .sql e vai criar métodos de versionamento (criando duas tabelas) no banco de dados.

Agora vamos imaginar que eu preciso fazer um update na tabela e meu banco de dados já está em produção. Vou crio um .sql com o SQL do update e adiciono ao liquibase. O liquibase vai rodar, ele mesmo vai reconhecer que o primeiro script sql (de criação da tabela) já foi rodado e vai rodar o segundo script (update).

Se o Banco de Dados for apagado, ao rodar o liquibase ele vai executar (na ordem configurada) os scripts sql configurados nele.

Acho uma ótima ferramenta, fácil de usar e pode ser usada em produção sem nenhum problema.

VOCÊ ESTÁ NAS SEÇÕES:  Banco de Dados » MySQL

Siga os bons!

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.

Sumário
Como versionar banco de dados MySQL
Nome do artigo
Como versionar banco de dados MySQL
Descrição
Uma grande dificuldade em se trabalhar com bancos de dados é que as mudanças chegam de dois lados: alterações de dados ocorrendo no ambiente de produção, e alterações de estrutura seguindo o processo "normal" (desenvolvimento, testes, qualidade, produção - ou seja qual for a progressão de ambientes que você/sua empresa use).
Autor
Nome
Ramos da Informática
Logo



Frontend Do Zero Ao Profissional