Sincronización de la base de datos de Wordpress entre dev y prod


19

Se ha preguntado antes sobre cómo sincronizar archivos y la base de datos entre dos instalaciones de Wordpress.

Para el nivel de la base de datos, la respuesta suele ser básicamente volcar una base de datos e insertarla en otro servidor. El problema con esto es que terminas perdiendo cualquier cambio que potencialmente se haya realizado en el servidor de producción. Por ejemplo, métricas de uso, comentarios, etc.

Con esto en mente, comencé a preguntarme si sería posible extender el ORM de Wordpress para que pueda generar deltas y luego inyectarlos en el sitio de producción.

¿Alguien ha intentado esto, investigándolo o tiene alguna idea o comentario?


1
Lo he investigado, sí, pero no he logrado mucho. Si pudiera señalar una prueba de concepto con otra plataforma CMS, estoy seguro de que podríamos reajustarla para WordPress.
EAMann

¿Qué tal la replicación?
kovshenin

Bien, la replicación con mysql requeriría alguna forma de replicación maestro-maestro que es un PITA. Si tiene en cuenta el hecho de que esto es entre dev y prod, entonces la replicación tendría que retrasarse, lo que probablemente se rompería todo el tiempo.
jonathanserafini

Respuestas:


11

La realidad es que lo que queremos es esto: http://www.liquibase.org/

Liquibase es una biblioteca de código abierto (Apache 2.0 con licencia), independiente de la base de datos para rastrear, administrar y aplicar cambios en la base de datos. Se basa en una premisa simple: todos los cambios en la base de datos se almacenan en una forma legible pero rastreable y se registran en el control de origen.

Sin embargo, nuestro proceso de desarrollo no lo admite. Por lo general, no modificamos la base de datos a través de secuencias de comandos discretas que escribimos nosotros mismos, utilizamos complementos que activamos. No escribimos scripts DML para modificar los datos de búsqueda que luego verificamos en el control del código fuente, utilizamos una interfaz de usuario en la página de administración y, por lo tanto, no tenemos código fuente para su uso posterior en la replicación de ese cambio durante la migración.

Sin embargo, podemos emular algunos de ellos, utilizando algunas de las herramientas enumeradas en esta página:

/programming//q/225772/149060

Por ejemplo, liquidbase tiene una función diff que también incluye opcionalmente cambios en los datos. Potencialmente, podríamos generar el esquema y la diferencia de datos en un script, excluyendo (como sea posible) ciertas tablas que probablemente incluyan datos de prueba (es decir, publicaciones, etc.) y luego aplicar el script a la base de datos de producción.

MySQLDiff (discutido en la pregunta de StackOverflow) hace diferencias de esquema, y ​​su autor recomienda mysql_coldiff para diferencias de datos en forma de tabla; ambas se implementan en perl, si las herramientas de Java (liquidbase) requieren demasiados recursos para sus servidores, aunque traiga ambas bases de datos locales y ejecutar la herramienta en tu PC resuelve ese problema ...

Si realmente queremos hacerlo bien, debemos registrar cualquier sql que esté relacionado con la configuración, las opciones u otros cambios de configuración, y cualquier cambio de esquema, y ​​convertir el código registrado en un script de migración para jugar en nuestro servidor de producción. Juegue el script de migración contra el servidor, copie los archivos del sitio de WordPress (excluyendo las cargas, si corresponde) y somos dorados.

Entonces, me parece que la mejor manera de salir es un plugin de desarrollador de migración del desarrollador que atrapa el sql que necesitamos, lo almacena y luego genera un script de migración a partir del código registrado, en lugar de crear una forma de fusionar bases de datos entre puesta en escena y producción. Parece un problema más simple de resolver también.

Si miramos el código del gancho de instrumentación de @bueltge llama al complemento de inspiración: https://gist.github.com/1000143 (gracias a Ron Rennick a través de G + por señalarme en la dirección de SAVEQUERIES y el gancho de apagado, eso llévame a encontrarlo)

- modifíquelo para obtener la salida SAVEQUERIES en su lugar 
- solo se ejecuta mientras está en admin 
- filtrar todas las selecciones 
- guardar resultados en la tabla en el gancho de apagado 
- podríamos alternar selectivamente la captura de salida en función de lo que estábamos haciendo en este momento.  

Por ejemplo:

Nombre de captura: Activar y configurar el complemento XYZ

Capture State Toggle - activado

... instalar y configurar el complemento XYZ

Capturar estado alternar - apagado

Exportar script de migración para: Activar y configurar el complemento XYZ

Presione el botón Exportar para generar un campo de texto emergente con el SQL atrapado filtrado, idealmente formateado previamente como un script de shell con llamada de línea de comandos a mysql. Cópielo y péguelo en su carpeta de código de migración y agréguelo a su repositorio de código fuente.

Atención cuidadosa para activar y desactivar la captura mientras trabaja y podrá generar el script de migración perfecto para llevar su base de datos de producción a una configuración equivalente a su base de datos provisional.

Lo que es mejor, tendrá un script (o una serie de los mismos) que puede PROBAR. ¡Imágenes con scripts de migración replicables, comprobables!

Ya estoy enamorado

¿Alguien mas?


2
Buena redacción. He pasado mucho tiempo en este problema porque tengo clientes que buscan nuestra ayuda. Es un problema realmente difícil, pero hemos decidido que bajar al nivel de SQL es probablemente una solución demasiado "hervir el océano" , lo que significa que las posibilidades de que funcione al 100% son poco probables. Creo que la solución es utilizar un enfoque de "divide y vencerás" con código explícito que entienda la estructura de WordPress y que proporcione ganchos para cualquier otra cosa. Espero que podamos presentar una solución viable públicamente en algún momento en el futuro.
MikeSchinkel

Entonces ... ¿quién quiere hacer esto?
Dave Kiss

para cualquiera que esté mirando, parece que esta misma idea está disponible como un complemento: wordpress.org/plugins/query-recorder
majick

3

El complemento de WordPress Sync de base de datos hace un gran trabajo al sincronizar datos entre dos servidores.

Por defecto, sobrescribe TODOS los datos de destino, sin embargo, acabo de implementar algunas mejoras en el complemento que le permiten sincronizar solo tablas de bases de datos específicas. Esto puede ayudarlo a retener comentarios, usuarios y otros datos que no desee sobrescribir. ¿Eso te da la granularidad que necesitas?

Todavía no he publicado mis cambios al público, pero si está interesado en una copia, envíeme un correo electrónico a simon-at-yump.com.au. Si alguien encuentra esto útil o tiene solicitudes de funciones adicionales, avíseme y veré qué puedo hacer.


ACTUALIZACIÓN: También acabo de encontrar el complemento WP-Sync-DB , que es una bifurcación del complemento comercial WP-Migrate-DB-Pro . Hace algo muy similar, aunque probablemente tenga más brillo que la sincronización de base de datos .


0

Existe un servicio comercial relativamente nuevo específicamente para esta tarea. Se llama RAMPA:

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


1
Hay limitaciones a ese servicio que hacen que no se ajuste a mi caso de uso:
marfarma

2
Mi caso de uso: agregar funcionalidad mientras que la producción agrega contenido. Cita: "Actualmente, los siguientes elementos no son compatibles: Configuración (configuración principal y de complementos, a menos que opten por RAMP)" 99.99% de las opciones y configuraciones de temas y complementos no se migrarán. Sin cambios de código en la producción, los post-tipos personalizados no migrarán. Olvídate de agregar tablas personalizadas y sus datos.
marfarma

1
Ese producto tiene un caso de uso válido: organizar el contenido y luego publicarlo. Lamentablemente, ese no es el problema que me preocupa. Volviendo al OP, no está claro con qué caso de uso se está enfrentando, por lo que podría ser la solución perfecta para su tienda.
marfarma
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.