Replicar o banco de dados principal MySql para um servidor de desenvolvimento para reproduzir dados reais

Question

Eu tenho uma arquitetura principal com um banco de dados MySql, replicação e backup, está funcionando bem. Agora eu também tenho um servidor de desenvolvimento onde eu jogo com o código e gostaria de usar os dados do banco de dados principal para jogar também, com leituras e gravações. Como posso configurar a replicação para ter alguns dados reais provenientes do banco de dados principal para o banco de dados de desenvolvimento? Devo replicar permanentemente ou apenas uma vez por dia para manter algum tipo de consistência durante os testes no devdb? Qualquer ideia / estratégia é bem vinda.

Edit: ok, então, para esclarecer o tipo de aplicativo que eu uso é um desenvolvimento de aplicativo da web com o Django. A ideia é testar alguns novos recursos no servidor de desenvolvimento. A necessidade de escrever é importante, um banco de dados somente leitura não será suficiente para executar os testes completamente. No momento, o banco de dados leva um tempo razoável para despejar para outro servidor (algo como 10 minutos), mas está crescendo.

    

Answer 1

A "resposta certa" é altamente dependente de aplicativos, mas aqui estão algumas estratégias que vi antes.

Backup diário / restauração sob demanda

Isso funciona bem se você tiver um pequeno conjunto de dados e a necessidade de ter vários desenvolvedores usando os backups ad-hoc. A ideia é basicamente um mysqldump em um sistema de destino de replicação e alguns scripts para fazer uma importação do MySQL.

Processo ETL

Essa abordagem faz muito sentido se você quiser um subconjunto de dados ou se quiser mascará-lo de alguma forma para proteger os dados contra violações. Você pode transformar dados confidenciais dentro dos scripts ETL e carregá-los diretamente em um banco de dados de desenvolvimento ou criar um dump como na abordagem acima, mas você saberá que já foi limpo.

Um processo ETL pode ser bom se você quiser executá-lo por hora para, digamos, extrair a última hora da produção, fazer alguma limpeza / reorganização e importá-lo para um banco de dados "mestre" de desenvolvimento para exportação para sistemas de desenvolvimento, etc.

Replicação de logs binários

Este método provavelmente não funcionará para você, como você deseja ler e para gravar no banco de dados de desenvolvimento. Às vezes, as pessoas usarão a replicação para executar testes de regressão somente leitura, mas a modificação do banco de dados resultará em replicação com falha e / ou dados inconsistentes.

    

Answer 2

depende dos aplicativos que você está desenvolvendo: um simples despejo ou uma replicação diária / semanal faria o truque, a menos que você precise testar como o aplicativo processa novos dados do servidor de produção; nesse caso, você precisará de um permanente replicação.

    

Answer 3

Tudo depende da quantidade de dados que você deseja replicar. Se o seu banco de dados muito pequeno você pode fazer o despejo diário e, em seguida, recriar o banco de dados no seu servidor de banco de dados de desenvolvimento. E você pode ler e escrever. Replicação no cenário onde você quer fazer escreve sobre escravo será bastante complicado (eu não tenho certeza, mas talvez imposible). Você não pode fazer gravações no escravo com o modelo mestre-escravo e no mestre-mestre qualquer gravação será replicada para outro mestre

    

Answer 4

Se você precisar de acesso de leitura / gravação, sugiro que você configure um trabalho cron que apenas copie o banco de dados de sua produção para o seu desenvolvimento.

profissionais: você tem acesso de gravação

contras: todo o seu trabalho será eliminado da próxima vez que você executar o cron job para atualizar o seu dbs

Se você precisar apenas de acesso somente leitura, sugiro que configure uma replicação usando o seguinte guia : MySQL :: Manual de Referência do MySQL 4.1 :: 16 Replication

pro: sempre atualizado

cons: não pode escrever, já que isso quebraria a replicação em algum momento.