¿Cómo fusionar bases de datos locales y en vivo?

Hemos estado desarrollando para WordPress durante varios años y, aunque nuestro flujo de trabajo se ha actualizado en varios puntos, hay una cosa que nunca hemos resuelto… fusionar una base de datos local de WordPress con una base de datos activa.

Así que estoy hablando de tener una versión local del sitio donde se cambian los archivos y los datos, mientras que los datos en el sitio en vivo también cambian al mismo tiempo.

Todo lo que puedo encontrar es el escenario mundial perfecto de derribar el sitio, nadie (ni siquiera los clientes) toca el sitio en vivo y luego vuelve a subir el sitio local. Es decir, copiar una cosa sobre la otra.

¿Cómo se puede hacer esto sin ejecutar una tonelada de comandos mysql? (¡Parece que podrían caerse si no se revisan correctamente!) ¿Se puede hacer esto a través de Gulp (lo he visto mencionado) o un complemento?

Para que quede claro, no estoy hablando de empujar/retirar datos de un lado a otro a través de algo como WP Migrar DB Pro, Compañero de copia de seguridad o algo similar: esta es una fusión, no reemplaza una base de datos con otra.

¡Me encantaría saber cómo solucionan esto otros desarrolladores!

Los cambios de archivos son bastante simples de sortear, es cuando hay cambios de datos que causan la pesadilla.

Diligencia WP hace una fusión pero no puede trabajar localmente, crea un sitio de prueba desde el sitio en vivo en el que se supone que debe trabajar. La combinación funciona muy bien, pero es un golpe mortal no poder trabajar localmente.

También me han dicho los desarrolladores que datahawk.io haré lo que quiera, pero no hay fecha de lanzamiento al respecto.

Parece que VersionPress podría hacer lo que necesita:

VersionPress puesta en escena

Un par de advertencias: no lo he usado, así que no puedo garantizar su efectividad; y actualmente se encuentra en acceso anticipado.

Importante: realice una copia de seguridad de la base de datos en vivo antes de fusionar los datos locales.

Seguir estos pasos puede ayudar a migrar el gran porcentaje de datos y fusionarlos para vivir

1. Ir al back-end de wp de sitio local Herramientas->Exportar.
2. Seleccione el botón de opción Todo el contenido (si no está seleccionado de forma predeterminada).
3. Esto traerá un archivo Xml que contiene todos los datos locales compuestos por todos los tipos de publicaciones predeterminadas y tipos de publicaciones personalizadas.
4. Abra este archivo XML en el bloc de notas ++ o cualquier editor y busque y reemplace la URL local con la URL en vivo.
5. Ahora visita el sitio en vivo e Importe el XML en Herramientas->Importar.
6. Cargue los archivos (imágenes) manualmente.

Esto traerá un gran porcentaje de datos de Local a Live.

El resto de los datos tendrá que escribir scripts personalizados.

Los factores de riesgo son:

1. Al cargar las imágenes de Local a Live, se anularán las imágenes del mismo nombre.
2. WordPress guarda las imágenes en post_meta generando datos serializados para las imágenes, que deben tenerse en cuenta al cargar la base de datos.
3. Datos serializados en post_meta para post_type="attachment" guarda datos serializados para 3 o 4 dimensiones de las imágenes.
4. Los nombres de usuario o las identificaciones de correo electrónico de los usuarios al importar los datos pueden ser iguales (o wp realiza la función de verificar nombres de usuario y correos electrónicos únicos), entonces esos usuarios no se importarán (podría ser posible).

Si yo fuera usted, haría lo siguiente (lento pero le brinda la mayor posibilidad de éxito)

En primer lugar, configure una tercera base de datos en alguna parte. Los servicios en la nube probablemente serían ideales, ya que podría obtener un servidor potente con un SSD durante un par de horas. Necesitarás esa potencia.

En segundo lugar, vamos a mysqldump la primera base de datos y canalice la salida a nuestra base de datos en la nube.

mysqldump -u user -ppassword dbname | mysql -u root -ppass -h somecloud.db.internet

Ahora tenemos una copia completa de DB #1. Si su nube admite instantáneas de datos, asegúrese de tomar una ahora.

El último paso es escribir un script PHP que, de forma lenta pero segura, seleccione los datos de la segunda base de datos y los escriba en la tercera. Queremos hacer esto un registro a la vez. ¿Por qué? Bueno, necesitamos mantener las relaciones entre los registros. Así que tomemos comentarios y publicaciones. Cuando extraigamos la publicación n. ° 1 de la base de datos n. ° 2, no podrá mantener el registro n. ° 1 porque la base de datos n. ° 1 ya tenía uno. Así que ahora la publicación n.° 1 se convierte en la publicación n.° 132. Eso significa que todos los comentarios de la publicación n.º 1 ahora deben escribirse como pertenecientes a la publicación n.º 132. También tendrá que extraer los registros de los usuarios que realizaron esas publicaciones, porque sus ID de usuario también cambiarán.

No hay una solución fácil para esto, pero la estructura de WP no es terriblemente compleja. Construir un bucle simple para extraer los datos y traducirlos no debería llevar más de un par de horas de trabajo.

Si te entiendo, para fusionar la base de datos local y en vivo, hasta ahora estoy usando otro software como NavicatPremiumtiene función de sincronización de datos.

Esto se puede lograr en vivo usando spring-xd, cree un JDBC Stream para extraer datos de un db e insertarlos en el otro. (Esto actúa como transmisión para que no tenga que perturbar ningún entorno)

Lo primero que debe hacer es evaluar si sería más fácil hacer una entrada de datos de copiar y pegar en lugar de un script de migración. A veces, la mejor respuesta es absorberlo y hacerlo manualmente usando la interfaz de CMS. Esto evita posibles conflictos con la combinación de claves principales, pero es posible que deba buscar referencias como el creador de una publicación o datos similares.

Si simplemente es demasiado para migrar manualmente, está obligado a escribir un script o encontrar uno que ya esté escrito para usted. Suponiendo que no haya nada ahí fuera, esto es lo que debe hacer…

¡HAZ SIEMPRE UNA COPIA DE SEGURIDAD ANTES DE REALIZAR MIGRACIONES!

1) Haz una lista de lo que necesitas transferir. ¿Necesitas usuarios, publicaciones, etc.? Busque las tablas de la base de datos y agréguelas a la lista.

2) Tome nota de todo lo posible llaves extranjeras en las tablas de la base de datos que se fusionan en la nueva base de datos. Por ejemplo, wp_posts posee post_author referenciando wp_users. Estos necesitarán una atención específica durante la migración. Utilizar este documentación para ayudar a encontrarlos.

3) Una vez que sepa qué tablas necesita y a qué hacen referencia, debe escribir el script. Comience por averiguar qué contenido es nuevo para la otra base de datos. La forma más segura es hacerlo manualmente con algún tipo de lista en paralelo. Sin embargo, puede crear sus propias reglas sobre cómo hacer coincidir automáticamente las filas de la tabla. Tal vez para comprobar $post1->post_content === $post2->post_content en casos el texto necesita ser el mismo. El único problema aquí es que las claves primarias/foráneas están fuera de los límites de estas reglas.

4) ¿Cómo te fusionas? nuevo ¿contenido? La idea general es que todas las claves principales deberán cambiarse para cualquier contenido nuevo. Desea usar todo excepto la identificación de la publicación e insertarla en la nueva base de datos. Habrá un incremento automático para crear la nueva identificación, por lo que no necesitará la identificación anterior (a menos que la desee para la salida/depuración del script).

5) La parte difícil es manejar las claves foráneas. Este proceso variará enormemente según lo que planee migrar. Lo que necesita saber es qué clave externa va a qué clave principal (posiblemente nueva). Si solo está migrando publicaciones, es posible que deba codificar una identificación de usuario para la asignación de identificación de usuario para el post_author columna, luego use esto para reemplazar los valores.

Pero, ¿qué sucede si no conozco los ID de usuario para la asignación porque algunos usuarios también deben migrarse?

Aquí es donde se pone complicado. Primero deberá definir las reglas de combinación para ver si ya existe un usuario. Para nuevo usuarios, necesita registrar la identificación de los usuarios recién insertados. Luego, después de migrar todos los usuarios, el post_author será necesario reemplazar el valor cuando haga referencia a un usuario recién fusionado.

6) ¡Escribe y prueba el guión! Pruébelo primero en bases de datos ficticias. Y otra vez, ¡haga copias de seguridad antes de usarlo en sus bases de datos!

He hecho algo similar con Proceso ETL (Extraer, Transformar, Cargar) cuando estaba moviendo datos de un CMS a otro.

En lugar de escribir un guión, utilicé un Herramienta Pentaho Data Integration (Kettle).

La idea de ETL es bastante sencilla:

• miextraer los datos (por ejemplo, de una base de datos)
• TTransfórmalo para que se adapte a tus necesidades.
• Lcárguelo hasta el destino final (su segunda base de datos).

La herramienta es fácil de usar y le permite experimentar con varios pasos y resultados para investigar los datos. Cuando diseña un proceso ETL correcto, está listo para fusionar esas bases de datos suyas.