Esta é a minha primeira vez aqui. Eu recentemente entrei como administrador de sistemas em uma empresa e minha recente tarefa é criar ambientes de desenvolvimento mais amigáveis para nossos desenvolvedores. Até agora, nossos desenvolvedores se conectam à nossa caixa remota, copiam o código de produção, fazem uma restauração do banco de dados de produção e corrigem as configurações do vache do apache e, em seguida, iniciam o desenvolvimento. A maior parte do desenvolvimento acontece via massa e é extremamente tedioso.
Recentemente aprendi sobre o Vagrant e fiquei impressionado com isso. Então eu rapidamente configurei uma simples pilha LAMP que nossos desenvolvedores podem usar. No entanto, minha maior complicação neste momento é como configurar um ambiente de produção como o mysql. Nosso banco de dados é em torno de 7 GB de tamanho e não faz sentido para baixá-lo e depois executá-lo em sua VM vagrant.
Tenho certeza de que esse é um problema comum que muitos administradores já lidaram no passado. Como faço para configurar um DB de desenvolvimento como o Vagrant, sem transferir esse despejo de dados massivo.
Nossos desenvolvedores usam um conjunto de dados menor do que um que está em produção. Todas as tabelas são as mesmas, mas os dados não são uma cópia do conjunto de dados em tempo real. Isso vai variar dependendo de suas necessidades, mas para nós essa é uma ótima maneira de trabalhar.
Basicamente, tenha um ambiente de desenvolvimento. A última vez que trabalhei com bancos de dados LARGE (e seriamente, o 7GB é TINY), o kit de desenvolvimento estava em torno de 10000gb. Usamos um dos três servidores que tínhamos - o de reserva para desastres reais - como uma caixa de desenvolvimento, pronto para ser apagado se os ops precisassem dele.
Agora trabalho em coisas menores (apenas cerca de 300 GB por banco de dados) e, falando sério, temos um pool central de servidores SQL de desenvolvimento que os desenvolvedores usam.
Você precisa de um ambiente adequado de teste e desenvolvimento - e mesmo com um banco de dados pequeno como o seu, isso é um pouco problemático. Espere até que você tenha pelo menos SMALL Databases. 7GB ainda é minúsculo.
Resolvemos esse problema. Nós começamos usando jetpants , uma ferramenta de código aberto MySQL sharding do tumblr. A partir daí, percebemos que não precisávamos da sincronização pontual imediata oferecida por jetpants, para simplificarmos ainda mais o backup noturno da produção armazenado como um arquivo. Comprimamos esse arquivo com o lzop e o enviamos para as máquinas dev através do netcat. Tempo do início ao fim para um DB de 20 GB? 4 minutos. Ajuda do SSD.
Enquanto o seu produto DB é de 7 GB - o tamanho é sem dados de atividade? (Dados de atividade são dados que são adicionados por usuários ou programas, enquanto dados de referência são dados que você precisa desativar para outras coisas. Um exemplo seria um registro de Endereço - o nome e endereço da rua são dados de atividade, já que foram adicionados por alguém, mas o tipo de endereço é um dado de referência - já que eles precisavam selecionar 'Home', 'Work' ou 'Other'.)
Com apenas os dados de esquema e referência, não deve ser demais criar uma nova instância em cada ambiente. Por algum motivo, se é, qual é o problema em ter desenvolvedores usando um banco de dados "Dev"?