Criando um banco de dados de teste com dados copiados * e * seus próprios dados

Question

Gostaria de criar um banco de dados de teste que seja atualizado todos os dias com dados do banco de dados de produção.

MAS , gostaria de poder criar registros no banco de dados de teste e retê-los, em vez de substituí-los.

Eu estou querendo saber se existe uma maneira simples e direta de fazer isso.

Ambos os bancos de dados são executados no mesmo servidor, aparentemente, isso exclui a replicação?

Para esclarecimentos, eis o que gostaria de acontecer:

1. O banco de dados de teste é criado com dados de produção
2. Eu crio alguns registros de teste que quero continuar executando no servidor de teste (basicamente para que eu possa ter registros de exemplo com os quais eu possa brincar)
3. No dia seguinte, o banco de dados é completamente atualizado, mas os registros criados naquele dia são mantidos. Registros que não foram tocados naquele dia são substituídos por registros do banco de dados de produção.

A complicação é que, se um registro no banco de dados de produção for excluído, também quero que ele seja excluído no banco de dados de teste; portanto, quero me livrar dos registros no banco de dados de teste que não existem mais no banco de dados de produção. a menos que esses registros tenham sido criados dentro do banco de dados de teste.

Parece que a única maneira de fazer isso seria ter algum tipo de tabela armazenando metadados sobre os registros que estão sendo criados? Então, por exemplo, algo assim:

CREATE TABLE MetaDataRecords (
    id integer not null primary key auto_increment,
    tablename varchar(100),
    action char(1),
    pk varchar(100)
);

DELETE FROM testdb.users
WHERE
    NOT EXISTS (SELECT * from proddb.users WHERE proddb.users.id=testdb.users.id) AND
    NOT EXISTS (SELECT * from testdb.MetaDataRecords 
        WHERE  
            testdb.MetaDataRecords.pk=testdb.users.pk AND
            testdb.MetaDataRecords.action='C' AND
            testdb.MetaDataRecords.tablename='users'
    );

    

Answer 1

Acho que você pode encontrar mesclar tabelas úteis aqui. Basta manter os dados de teste em uma tabela; e ter instantâneos diários da produção em outra tabela; e ter mesclar tabela desses dois.

    

Answer 2

Eu estive aqui e estava disposto a modificar um pouco o meu fluxo de trabalho para minimizar o risco de ter dados de produção que deveriam ter sido substituídos, no banco de dados de testes.

Tudo o que fiz foi simplesmente:

• mysqldump da produção
• Injete SQL até o final do dump e assert está no arquivo (nunca é muito cuidadoso com as gravações de arquivos)
• Restaure este backup no banco de dados de teste.

O SQL que você injeta deve ser mantido separadamente, talvez em outro script. Estes são geralmente chamados de equipamentos de teste . Para abstrair a sua implementação de banco de dados e confiar menos em "mágica" (ou seja, no seu caso, diff ing seu banco de dados de teste com sua restauração anterior para ver o que foi adicionado, então ver o que é removido de ao vivo, referência cruzada primária / chaves estrangeiras e tal) para que haja uma chance muito menor de estragar tudo, e você acaba enviando e-mails para seus usuários reais em vez dos seus testes.

Uma vantagem (para mim) é algo como:

UPDATE users SET email = CONCAT('gmailusername+', users.name, '@gmail.com')';

que é um mega-failsafe caso todas as outras avenidas falhem (como o seu servidor SMTP simulado), e o email escorregue (novamente, nunca será muito cuidadoso com essas coisas).