Sincronização de banco de dados Wordpress entre dev e prod


19

A pergunta foi feita antes sobre como sincronizar arquivos, bem como o banco de dados entre duas instalações do Wordpress.

Para o nível do banco de dados, a resposta geralmente é despejar um banco de dados e inseri-lo em outro servidor. O problema é que você acaba perdendo as alterações que foram potencialmente feitas no servidor prod. Por exemplo, métricas de uso, comentários, etc ...

Com isso em mente, comecei a me perguntar se seria possível estender o Wordpress ORM para que você possa gerar deltas e injetá-los no site do prod.

Alguém já tentou isso, olhando para ele, ou tem alguma idéia ou comentário?


1
Eu olhei para ele, sim, mas não consegui muito. Se você puder apontar para uma prova de conceito com outra plataforma CMS, tenho certeza de que poderíamos revogá-la para o WordPress.
EAMann

E a replicação?
precisa saber é o seguinte

A replicação de um poço com mysql exigiria alguma forma de replicação master-master, que é uma PITA. Se você levar em consideração o fato de que isso ocorre entre dev e prod, a replicação terá que ser adiada, o que provavelmente quebrará o tempo todo.
Jonathanserafini

Respostas:


11

A realidade é que o que queremos é este: http://www.liquibase.org/

O Liquibase é uma biblioteca independente de banco de dados de código aberto (Apache 2.0 Licensed) para rastrear, gerenciar e aplicar alterações no banco de dados. Ele é construído com base em uma premissa simples: todas as alterações no banco de dados são armazenadas em um formato legível por humanos e ainda rastreável e verificadas no controle de origem.

No entanto, nosso processo de desenvolvimento não o suporta. Normalmente não modificamos o banco de dados através de scripts discretos que escrevemos, usamos plugins que ativamos. Nós não escrevemos scripts DML para modificar os dados de pesquisa que verificamos no controle do código-fonte, usamos uma interface do usuário na página de administração e, portanto, não temos código-fonte para uso posterior na replicação dessa alteração durante a migração.

No entanto, podemos emular parte disso - usando algumas das ferramentas listadas nesta página:

/programming//q/225772/149060

Por exemplo, o liquidbase possui um recurso diff que também inclui opcionalmente alterações nos dados. Poderíamos, potencialmente, gerar a saída do esquema e dos dados para um script, excluindo (quanto possível) determinadas tabelas que provavelmente incluíssem dados de teste (por exemplo, pós, etc.) e depois aplicá-lo ao banco de dados de produção.

O MySQLDiff (discutido na questão StackOverflow) faz diffs de esquema, e seu autor recomenda mysql_coldiff para diffs de dados em tabela - ambos são implementados em perl, se as ferramentas java (liquidbase) são muito pesadas em recursos para seus servidores - embora tragam ambos os bancos de dados locais e executar a ferramenta no seu PC resolve esse problema ...

Se realmente queremos fazer isso corretamente, devemos registrar qualquer sql relacionado a configurações, opções ou outras alterações de configuração e quaisquer alterações de esquema - e converter o código registrado em um script de migração para jogar contra o nosso servidor de produção. Jogue o script de migração no servidor, copie os arquivos do site wordpress (excluindo uploads, se aplicável) e somos o ouro.

Então, parece-me que a melhor saída é o plug-in de migração-construtor de desenvolvedores que intercepta o sql de que precisamos, o armazena e gera um script de migração a partir do código registrado, em vez de criar uma maneira de mesclar bancos de dados entre preparação e produção. Parece um problema mais simples de resolver também.

Se olharmos para o código do gancho de instrumentação do @bueltge chama o plug-in para obter inspiração: https://gist.github.com/1000143 (obrigado a Ron Rennick via G + por me apontar na direção de SAVEQUERIES e do gancho de desligamento, esse leve-me a encontrá-lo)

- altere para obter a saída SAVEQUERIES 
- executar apenas enquanto estiver no admin 
- filtrar todas as seleções 
- salve os resultados na tabela no gancho de desligamento 
- podemos alternar seletivamente a captura de saída com base no que estávamos fazendo no momento.  

Por exemplo:

Nome da captura: Ative e configure o plug-in XYZ

Alternar estado de captura - ativado

... instalar e configurar o plug-in XYZ

Alternar estado de captura - desativado

Exportar script de migração para: Ativar e configurar o plug-in XYZ

Pressione o botão Exportar - para produzir um campo de texto pop-up com o SQL interceptado filtrado - idealmente pré-formatado como um script de shell com chamada de linha de comando para o mysql. Copie e cole na pasta de código de migração e adicione ao seu repositório de código-fonte.

Atenção cuidadosa para ativar e desativar a captura enquanto estiver trabalhando e você poderá gerar o script de migração perfeito para levar seu banco de dados de produção para uma configuração equivalente ao seu banco de dados temporário.

O que é melhor, você terá um script (ou série do mesmo) que poderá TESTAR. Imagem com scripts de migração replicáveis, testáveis!

Eu já estou apaixonado.

Alguém mais?


2
Boa redação. Passei muito tempo com esse problema porque tenho clientes procurando nossa ajuda. É um problema muito difícil, mas decidimos que descer para o nível do SQL é provavelmente uma solução "ferva o oceano" demais, o que significa que as chances de fazê-lo funcionar 100% são improváveis. Acho que a solução é usar uma abordagem de "dividir e conquistar" com código explícito que entende a estrutura do WordPress e que fornece ganchos para qualquer outra coisa. Espero que possamos apresentar uma solução viável publicamente em algum momento no futuro.
MikeSchinkel

Então .... quem quer fazer isso?
Dave Kiss,

para quem procura, parece que esta mesma ideia está disponível como um plugin: wordpress.org/plugins/query-recorder
majick

3

O plug-in de sincronização de banco de dados do WordPress faz um ótimo trabalho de sincronização de dados entre dois servidores.

Por padrão, ele substitui TODOS os dados de destino, no entanto, acabamos de implementar algumas melhorias no plug-in que permitem sincronizar apenas tabelas específicas do banco de dados. Isso pode ajudá-lo a reter comentários, usuários e outros dados que você não deseja substituir. Isso fornece a granularidade de que você precisa?

Ainda não liberei minhas alterações ao público, mas se você estiver interessado em uma cópia, envie-me um email em simon-at-yump.com.au. Se alguém achar isso útil ou tiver solicitações de recursos adicionais, informe-me e verei o que posso fazer.


ATUALIZAÇÃO: Acabei de encontrar o plug - in WP-Sync-DB , que é um fork do plug - in comercial WP-Migrate-DB-Pro . Faz uma coisa muito semelhante, embora provavelmente tenha mais polimento que o Database Sync .


0

Existe um serviço comercial relativamente novo especificamente para esta tarefa. Chama-se RAMP:

http://alexking.org/blog/2011/07/20/ramp-content-deploy-wordpress


1
Existem limitações para que o serviço que o tornam não encaixam no meu caso de uso:
marfarma

2
Meu caso de uso - adicionando funcionalidade enquanto a produção adiciona conteúdo. Citação: "No momento, os seguintes itens não são suportados: Configurações (configurações principais e de plug-in, a menos que optem pela RAMP)" 99,99% das opções e configurações de temas e plug-ins não serão migradas. Sem alterações de código na produção, os tipos de postagem personalizados não serão migrados. Esqueça a adição de tabelas personalizadas e seus dados.
marfarma

1
Esse produto tem um caso de uso válido - preparando o conteúdo e, em seguida, fornecendo-o ao vivo. Infelizmente esse não é o problema que me preocupa. Voltando ao OP, não está claro em qual caso de uso ele está lidando - portanto, pode ser a solução perfeita para a loja deles.
marfarma
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.