Pergunta

Há muito tempo que mantemos nossos dados no repositório do projeto.Apenas mantivemos tudo em data/sql, e cada tabela tinha seus próprios arquivos create_tablename.sql e data_tablename.sql.

Acabamos de implantar nosso segundo projeto no Scalr e percebemos que é um pouco confuso.

A forma como implantamos:

Temos uma coleção de scripts "packageup" que separa o projeto em 3 arquivos (dados, código, arquivos estáticos) que armazenamos em 3 buckets separados no S3.

Sempre que uma função é iniciada, ela baixa um dos arquivos (dependendo da função:data, nfs ou web) e então um script "unpackage" configura tudo para cada função, carrega os dados no mysql, configura o nfs, etc.

Fazemos assim porque não queremos salvar imagens do servidor, sempre começamos com instâncias simples nas quais instalamos tudo do zero usando vários scripts criados internamente.O tempo de inicialização não é um problema (temos um farm pronto para uso em 9 minutos).

O problema é que é difícil tentar encontrar a versão correta do banco de dados sempre que tentamos configurar uma nova compilação de desenvolvimento (a qualquer momento, temos cerca de 4 compilações de desenvolvimento para um projeto).Além disso, o git está começando a engasgar quando entramos em produção, já que os arquivos sql acabam totalizando cerca de 500 MB.

A questão é:

Como todo mundo está gerenciando bancos de dados?Estou procurando algo que facilite a transferência de dados da produção para o desenvolvimento e também a migração de dados do desenvolvimento para a produção, mas não encontrei nada.

Foi útil?

Solução

Você deve dar uma olhada seriamente no DBDeploy (dbdeploy.com). É portado para muitos idiomas, sendo os principais Java e PHP. É integrado em ferramentas de construção como Ant e Phing e permite o compartilhamento fácil dos chamados arquivos delta.

Um arquivo delta sempre consiste em uma seção de implantação, mas também pode conter uma seção de desfazer. Quando você compromete seu arquivo Delta e outro desenvolvedor, ele pode apenas executar o DBDELAPE e todas as novas alterações são aplicadas automaticamente ao seu banco de dados.

Estou usando o DBDeploy para o meu blog de código aberto, para que você possa dar uma olhada em como os arquivos Delta são organizados: http://site.svn.dasprids.de/trunk/sql/deltas/

Outras dicas

Pelo que entendi, sua questão principal é a experiência de outras pessoas na migração de dados SQL do desenvolvimento para a produção.

Eu uso o Microsoft SQL Server em vez do My SQL, então não tenho certeza se minha experiência você pode usar diretamente.No entanto, desta forma funciona muito bem.

Eu uso a edição Visual Studio 2010 Ultimate para comparar dados em dois bancos de dados.O mesmo recurso existe também no Vinsual Studio Team Edition 2008 (ou edição Database).Você pode ler http://msdn.microsoft.com/en-us/library/dd193261.aspx para entender como funciona.Você pode comparar dois bancos de dados (dev e prod) e gerar script SQL para modificar os dados.Você pode excluir facilmente algumas tabelas ou colunas da comparação.Você também pode examinar os resultados e excluir algumas entradas da geração do script.Assim, é possível gerar scripts de maneira fácil e flexível que podem ser usados ​​​​para implantação das alterações no banco de dados.Você pode comparar separadamente os dados de dois bancos de dados da estrutura (comparação de esquema).Assim, você pode atualizar os dados no dev com os dados do prod ou gerar scripts que modificam o banco de dados prod para a última versão do banco de dados dev.Eu recomendo que você dê uma olhada nesses recursos e em alguns produtos de http://www.red-gate.com/ (como http://www.red-gate.com/products/SQL_Compare/index.htm).

Verificação de saída Capistrano. É uma ferramenta que a comunidade Ruby usa para implantação em diferentes ambientes e acho isso realmente útil.

Além disso, se sua implantação estiver começando a sufocar uma ferramenta Twitter chamada chamada Assassinato.

Pessoalmente, eu olhava para o Toad

http://www.toadworld.com/

Menos de 10k;) ... analisará estruturas de banco de dados, produzirá scripts para modificá -los e também migrará dados.

Uma parte da solução é capturar a versão de cada um dos seus módulos de código e os recursos de dados correspondentes em um único local e compará -los para garantir a consistência. Por exemplo, um incremento no número da versão do seu, digamos, customer_comments O módulo exigirá um arquivo SQL Delta correspondente para atualizar as tabelas de banco de dados relevantes para o número da versão igual para os dados.

Por exemplo, dê uma olhada no Magento's core_resource abordagem Conforme documentado por @AlaNStorm.

Saúde, JD

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top