Como posso colocar uma base de dados sob o git (controle de versão)?
estou a fazer uma aplicação web, e preciso de fazer uma ramificação para algumas alterações importantes, o que se passa é que estas alterações requerem alterações no esquema da base de dados, por isso, gostaria de colocar toda a base de dados sob o git também.
Como faço isso? existe uma pasta específica que eu possa manter sob um repositório git? Como sei qual? Como posso ter a certeza que estou a colocar a pasta certa? Preciso de ter a certeza, porque estas mudanças não são compatíveis com o passado. ate.a base de dados no meu caso é PostgreSQL
editar:
Alguém sugeriu tirar cópias de segurança e colocar o ficheiro de cópia de segurança sob controlo de versão em vez da base de dados. Para ser honesto, acho isso muito difícil de engolir.tem de haver uma maneira melhor.
actualização:
Está bem, não há melhor maneira, mas ainda não estou convencido, por isso vou mudar um pouco a pergunta: Eu gostaria de colocar toda a base de dados sob controle de versão., que Motor de banco de dados Posso usar para que eu possa colocar o banco de dados real sob controle de versão em vez de seu dump?o sqlite seria git-friendly?
Como este é apenas o ambiente de desenvolvimento, posso escolher o banco de dados que quiser.Edit2:
o que eu realmente quero não é acompanhar o Meu Histórico de desenvolvimento, mas ser capaz de mudar do meu ramo" novas mudanças radicais "para o" ramo estável atual " e ser capaz, por exemplo, de corrigir alguns erros/problemas, etc, com o ramo estável actual. De tal forma que quando eu mudar de ramificações, o banco de dados auto-magicamente torna-se compatível com o ramo em que estou atualmente. Não me importo muito com os dados reais.
24 answers
Se você está fazendo grandes mudanças, você deve ter um banco de dados secundário que você faz as alterações do novo esquema e não tocar o antigo, uma vez que como você disse que está fazendo um branch.
Verifica as bases de dados de Refactoring ( http://databaserefactoring.com/) para um monte de boas técnicas para manter o seu banco de dados em conjunto com alterações de código.
Basta dizer que estás a fazer as perguntas erradas. Em vez de colocar a sua base de dados no git, deverá estar a decompor as suas alterações em pequenos passos verificáveis para que possa migrar/reverter as alterações do esquema com facilidade.Se você quer ter total recuperabilidade você deve considerar arquivar o seu postgres Wal logs e usar o PITR (ponto na recuperação de tempo) para reproduzir transações back/forward para estados de bem conhecidos específicos.
- duplicar a base de dados, (tanto o esquema como os dados).
- no ramo para as novas alterações maiores, basta alterar a configuração do projecto para usar a nova base de dados duplicada.
Editar:
Por duplicado, quero dizer criar outra base de dados com um diferente nome (como {[[0]}); não fazer uma lixeira ou algo do género.Em vez de despejar manualmente o seu DB e guardá-lo no git, use fora da escala DataGrove.
O DataGrove é basicamente um controlo de versões DB-ele acompanha as alterações em todo o DB (esquema e dados) e permite-lhe marcar as versões no seu repositório. Você pode usá-lo ao lado do git e tê-lo marcar uma versão cada vez que você check-in Código, e carregar o estado DB direito sempre que você puxar o código.
Especificamente em relação a "Edit 2" - com DataGrove você pode simplesmente ter dois ramos do DB, um para cada um de vocês. Quando você carrega um determinado ramo do Código, DataGrove irá automaticamente recriar todo o estado DB, com todos os dados dentro para essa versão/ branch. Isto significa que você pode alternar entre ramos de desenvolvimento com um único, simples comando.Use algo do tipo LiquiBase Isto permite-lhe manter o controlo de revisão dos seus ficheiros da Liquibase. você pode marcar alterações apenas para a produção, e ter lb manter o seu DB atualizado para a produção ou desenvolvimento, (ou qualquer esquema que você quiser).
Existe uma ferramenta que está em desenvolvimento chamada Klonio , cuja versão beta está disponível para uso. Ele suporta MongoDB e MySQL a partir de agora.
Claro que tem integração com o git e você pode fotografar o seu esquema sozinho ou mesmo os dados incluídos.
Http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html
Http://www.red-gate.com/products/sql-development/sql-source-control/
Esta ferramenta é um snap de estúdio de gestão de servidores SQL, que lhe permitirá colocar a sua base de dados sob controlo de código com o Git.
É um pouco caro a $ 495 por usuário, mas há um teste gratuito de 28 dias disponível.Nota Não sou afiliado ao RedGate de forma alguma.
Eu me deparei com esta questão, pois eu tenho um problema semelhante, onde algo que se aproxima de uma estrutura de diretório baseada em DB, armazena 'arquivos', e eu preciso do git para geri-lo. É distribuído, através de uma nuvem, usando a replicação, portanto o seu ponto de acesso será através de MySQL.
A essência das respostas acima, parecem sugerir uma solução alternativa para o problema perguntado, que tipo de falha o ponto, de usar Git para gerenciar algo em uma base de dados, então eu vou tentar responde a essa pergunta.
Git é um sistema, que em essência armazena uma base de dados de deltas (diferenças), que pode ser remontada, a fim de reproduzir um contexto. O uso normal do git assume que o contexto é um sistema de arquivos, e aqueles deltas são diff's nesse sistema de arquivos, mas realmente todo git é, é um banco de dados hierárquico de deltas (hierárquico, porque na maioria dos casos cada delta é um commit com pelo menos 1 pais, dispostos em uma árvore).
Desde que consigas gerar um delta, em teoria, o git pode armazená-lo. O problema é que normalmente o git espera que o contexto, no qual está gerando o delta seja um sistema de arquivos, e da mesma forma, quando você verifica um ponto na hierarquia do git, ele espera gerar um sistema de arquivos.Se você quiser gerenciar mudanças, em uma base de dados, você tem 2 problemas discretos, e eu iria abordá-los separadamente (se eu fosse você). O primeiro é o esquema, o segundo são os dados (embora na sua pergunta, você declare dados não é algo que você está preocupado). Um problema que eu tinha no passado, era um banco de dados Dev e Prod, onde o Dev poderia levar mudanças incrementais ao esquema, e essas mudanças tinham que ser documentadas no CVS, e propogadas para viver, juntamente com adições a uma de várias tabelas 'estáticas'. Fizemos isso com uma terceira base de dados, chamada Cruise, que continha apenas os dados estáticos. Em qualquer ponto o esquema de Dev e Cruise poderia ser comparado, e nós tínhamos um script para pegar o diff desses 2 arquivos e produzir um arquivo SQL contendo ALTER declarações, para aplicá-lo. Da mesma forma, qualquer novo dado, poderia ser destilado para um arquivo SQL contendo comandos de inserção. Desde que Campos e tabelas sejam adicionados apenas, e nunca apagados, o processo poderia automatizar gerando as declarações SQL para aplicar o delta.
O mecanismo pelo qual git gera deltas é {[[0]} e o mecanismo pelo qual combina 1 ou mais deltas com um arquivo, é chamado merge. Se você pode criar um método para a difusão e fusão a partir de um contexto diferente, git deve funcionar, mas como já foi discutido você pode preferir uma ferramenta que faz isso para você. O meu primeiro pensamento para resolver isso é este https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools qual dos detalhes de como substituir a ferramenta interna de diferenças e junção do git. Eu vou atualizar esta resposta, como eu chegar com uma melhor solução para o problema, mas no meu caso eu espero apenas ter que gerenciar alterações de dados, em-até-agora-como um filestore baseado em DB pode mudar, então o meu a solução pode não ser exatamente o que você precisa.
Você não pode fazer isso sem atomicidade, e você não pode obter atomicidade sem usar pg_dump ou um sistema de arquivos snapshotting.
A minha instância de postgres está em zfs, que eu tiro ocasionalmente. É aproximadamente instantâneo e consistente.
O que você quer, em espírito, é talvez algo como Post Facto , que armazena versões de um banco de dados em um banco de dados. Verifique esta apresentação.
O projecto aparentemente nunca foi a lado nenhum, por isso provavelmente não o ajudará imediatamente, mas é um conceito interessante. Receio que fazer isto correctamente seja muito difícil, porque até a versão 1 teria de acertar todos os pormenores para que as pessoas confiassem no seu trabalho.Os Postgres e o mysql são mais complicados, uma vez que os dados binários são mantidos em vários ficheiros e podem nem ser válidos se for capaz de os fotografar.
Quero fazer algo semelhante, adicionar as alterações da minha base de dados ao meu sistema de controlo de versões.
Vou seguir as ideias deste post de Vladimir Khorikov "Banco de dados versioning best practices". Em resumo, irei
- armazene o seu esquema e os dados de referência num sistema de controlo da fonte.
- para cada modificação vamos criar um script SQL separado com as alterações
$pg_dump --schema ...
Para descarregar as tabelas, sequências, etc e colocar este ficheiro sob controlo de versão. Vai usar isto para separar as alterações de compatibilidade entre os seus ramos.
Em seguida, execute um dump de dados para o conjunto de tabelas que contêm a configuração necessária para a sua aplicação funcionar (provavelmente deverá ignorar os dados do Utilizador, etc), como o formulário valores por omissão e outros dados não modificáveis pelo utilizador. Você pode fazer isso seletivamente usando:
$pg_dump --table=.. <or> --exclude-table=..
Esta é uma boa ideia porque o repo pode ficar realmente desajeitado quando a sua base de dados chega a 100Mb+ ao fazer uma descarga completa de dados. Uma idéia melhor é fazer backup de um conjunto mais mínimo de dados que você precisa para testar o seu aplicativo. Se seus dados padrão é muito grande, no entanto, isso ainda pode causar problemas.
Se precisas mesmo de colocar cópias de segurança completas no repo, considera fazê - lo num ramo. fora da tua árvore de origem. Um sistema de backup externo com alguma referência ao SVN rev correspondente é provavelmente o melhor para isso.Também sugiro usar o formato de texto dumps sobre o binário para fins de revisão (pelo menos para o esquema), uma vez que estes são mais fáceis de diff. Você pode sempre comprimir estes para salvar o espaço antes de fazer o check-in.
Finalmente, dê uma olhada na documentação de backup postgres Se você ainda não o fez. A forma como estás a comentar o apoio ao a base de dados' em vez de um dump faz-me pensar se está a pensar em cópias de segurança baseadas no sistema de ficheiros (ver secção 23.2 for caveats).
Se precisar de controlo de revisão com algum grau de granularidade, por exemplo, diariamente, poderá juntar o resultado de texto das tabelas e do esquema com uma ferramenta como rdiff-backup, que faz cópias de segurança incrementais. A vantagem é que em vez de armazenar instantâneos de backups diários, você simplesmente armazenar as diferenças do anterior dia.
Com isso você tem a vantagem do controle de revisão e não desperdiça muito espaço.Em qualquer caso, usar o git directamente em ficheiros grandes planos que mudam muito frequentemente não é uma boa solução. Se o seu banco de dados se tornar muito grande, git vai começar a ter alguns problemas de gestão dos arquivos.
Eu recomendaria neXtep para a versão controlar o banco de dados tem um bom conjunto de documentação e fóruns que explica como instalar e os erros encontrados. Eu testei para postgreSQL 9.1 e 9.3, eu fui capaz de fazê-lo funcionar para 9.1 mas para 9.3 não parece funcionar.
Armazenar cada nível de alterações da base de dadossob o controlo de versionamento do git é como carregar a sua base de dados inteiracom cada commit e Restaurar toda a sua base de dados com cada atracção. Se a sua base de dados é tão propensa a alterações cruciais e não se pode dar ao luxo de as Perder, pode apenas actualizar os seus ganchos pre_ commit e post_merge. Eu fiz o mesmo com um dos meus projetos e você pode encontrar as direções aqui.
Uma vez que a sua escolha livre sobre o tipo DB usa um DB baseado em ficheiros, como por exemplo firebird.
Crie um modelo DB que tenha o esquema que se encaixa no seu ramo real e o guarde no seu repositório.
Ao executar a sua aplicação programaticamente criar uma cópia do seu modelo DB, armazená-lo noutro lugar e trabalhar apenas com essa cópia.
Desta forma pode colocar o seu esquema DB sob controlo de versão sem os dados. E se mudares o seu esquema só tem de alterar o modelo DB
Em cada máquina, tínhamos os ficheiros PHP, mas também o serviço MySQL, e uma pasta com imagens que os utilizadores enviariam. O servidor ao vivo cresceu para ter cerca de 100K (!) utilizadores recorrentes, o dump foi de cerca de 2GB (!), a pasta de imagem era de cerca de 50GB (!). Quando saí, o nosso servidor estava atingindo o limite de sua CPU, Ram, e acima de tudo, os limites de conexão líquida concorrente (nós até compilamos nossa própria versão de driver de cartão de rede para max fora do servidor 'lol'). Nós não poderíamos (nem você deveria assumir com o seu site) colocar 2GB de dados e 50GB de imagens no GIT.
Para gerir tudo isto no GIT facilmente, ignoraríamos as pastas binárias (as pastas que contêm as imagens) inserindo estes caminhos de pastas .gitignore. Também tínhamos uma pasta chamada SQL lá fora. a localização do documento Apache. Nessa pasta SQL, nós colocaríamos nossos arquivos SQL dos desenvolvedores em números incrementais (001.florianm.sql, 001.Joao.SQL, 002.florianm.sql, etc). Estes arquivos SQL também foram gerenciados pelo GIT. O primeiro ficheiro sql conteria, de facto, um grande conjunto de DB schema. Nós não adicionamos dados de usuário no GIT (por exemplo, os registros da tabela de usuários, ou a tabela de comentários), mas os dados como configus ou topologia ou outros dados específicos do site, foram mantidos nos arquivos sql (e, portanto, pelo GIT). Principalmente os desenvolvedores (que conhecem melhor o código) que determinam o que e o que não é mantido pelo GIT em relação ao SQL schema e dados.
Quando chegou a uma versão, o administrador regista-se no servidor dev, junta a ramificação ao vivo com todos os programadores e necessita de ramificações na máquina dev para uma ramificação de actualização, e empurra-a para o servidor de teste. No servidor de teste, ele verifica se o processo de atualização para o servidor ao vivo ainda é válido, e em rápida sucessão, aponta todo o tráfego no Apache para um site de substituição, cria um dump DB, aponta o diretório de trabalho de 'live ' para' update', executa todos os novos arquivos sql no mysql, e recoloca o tráfego de volta para o site correto. Quando todos os stakeholders concordaram depois de rever o servidor de teste, o administrador fez a mesma coisa de servidor de teste para servidor ao vivo. Depois, ele funde o ramo ao vivo no servidor de produção, para o ramo mestre across todos os servidores, e reajustou todos os ramos ao vivo. Os desenvolvedores foram responsáveis eles próprios para refazer seus ramos, mas eles geralmente sabem o que estão fazendo.
Se houvesse problemas no servidor de teste, por exemplo. a fusão teve muitos conflitos, então o código foi revertido (apontando o ramo de trabalho de volta para 'live') e os arquivos sql nunca foram executados. No momento em que os arquivos sql foram executados, isso foi considerado como uma ação não reversível na época. Se os arquivos SQL não estavam funcionando corretamente, então o DB foi restaurado usando o Dump (e os desenvolvedores told off, for providing ill-tested SQL files).
Hoje, mantemos uma pasta SQL-up e sql-down, com nomes de ficheiros equivalentes, onde os programadores têm de testar que ambos os ficheiros SQL actualizados podem ser igualmente desclassificados. Isso poderia ser executado com um script bash, mas é uma boa idéia se os olhos humanos continuassem monitorando o processo de atualização.
Não é grande, mas é controlável. Espero que isto dê uma visão sobre um site da vida real, prático, relativamente de alta disponibilidade. Seja um pouco antiquado, mas seguido.Use uma ferramenta como as migrações iBatis (manual, vídeo curto tutorial ) que lhe permite controlar a versão as alterações que faz a uma base de dados ao longo do ciclo de vida de um projecto, em vez da própria base de dados.
Isto permite-lhe aplicar selectivamente as alterações individuais a diferentes ambientes, manter um changelog do qual as alterações são em que ambientes, criar programas para aplicar as alterações a A A N, as alterações de rollback, etc.
Eu gostaria de colocar toda a base de dados sob controle de versão. motor de banco de dados Posso usar para que eu possa colocar a base de dados real sob controlo de versão em vez da lixeira?
Isto não é dependente do motor da base de dados. Por Microsoft SQL Server existem muitos programas de controle de versões. Eu não acho que esse problema pode ser resolvido com o git, você tem que usar um sistema de controle de versão do esquema específico pgsql. Não sei se tal coisa existe ou não...
- separar dados e esquemas e dados por omissão.
A configuração da base de dados é armazenada num ficheiro de configuração que não está sob controlo de versões (.gitignore)
Os valores por omissão da base de dados (para configurar novos projectos) são um ficheiro SQL simples sob controlo de versões.
Para o esquema da base de dados, crie um esquema da base de dados sob o controlo da versão.
A forma mais comum é ter programas de actualização que contém declarações SQL, (ALTER Table.. or UPDATE). Você também precisa ter um lugar na sua base de dados onde você grava a versão atual do seu esquema)
Dê uma olhada em outros grandes projetos de banco de dados open source (piwik,ou o seu favorito sistema cms), todos eles usam updatescripts (1.sql,2.sql,3.sh,4.php.5.sql)
Mas este é um trabalho muito intensivo de tempo, você tem que criar, e testar os updatescripts e você precisa executar um updatescript comum que compara a versão e executar todos os necessários actualizar os Guiões.
Então teoricamente (e é isso que eu procuro) você poderia largou o esquema da base de dados após cada alteração (manualmente, conjob, git hooks (talvez antes de persistir)) (e apenas em alguns casos muito especiais Criar updatescripts)Depois disso, no seu updatescript comum (execute o updatescript normal, para os casos especiais) e depois compare os esquemas (o dump e a base de dados actual) e, em seguida, gerar automaticamente as declarações alteradoras nessesary. Há algumas ferramentas que já posso fazer isto, mas ainda não encontrei um bom.
Enfrentei uma necessidade semelhante e aqui está o que a minha pesquisa sobre sistemas de controlo de versões de bases de dados vomitou:
- open source baseado em Sqitch-perl; disponível para todas as principais bases de dados, incluindo PostgreSQL https://github.com/sqitchers/sqitch
- Mahout-apenas para o controlo de versões PostgreSQL; open source database schema. https://github.com/cbbrowne/mahout
- Liquibase-outro código aberto db controlo de versões sw. versão livre do Datical. http://www.liquibase.org/index.html
- Versão Datalicomercial de Liquibase - https://www.datical.com/ Flyway by BoxFuse-commercial sw. https://flywaydb.org/
- outro projecto de código aberto https://gitlab.com/depesz/Versioning O autor fornece um guia aqui: https://www.depesz.com/2010/08/22/versioning/
- Mudança de porta vermelha automatização-apenas para o servidor SQL. https://www.red-gate.com/products/sql-development/sql-change-automation/