Wie werden lokale und Live-Datenbanken zusammengeführt?

Wir entwickeln seit mehreren Jahren für WordPress und obwohl unser Workflow an mehreren Stellen aktualisiert wurde, gibt es eine Sache, die wir nie gelöst haben … das Zusammenführen einer lokalen WordPress-Datenbank mit einer Live-Datenbank.

Ich spreche also von einer lokalen Version der Site, auf der Dateien und Daten geändert werden, während sich gleichzeitig auch die Daten auf der Live-Site ändern.

Alles, was ich finden kann, ist das perfekte Weltszenario, bei dem die Website heruntergefahren wird, niemand (sogar Kunden) die Live-Website berührt und dann die lokale Website wieder hochfährt. Dh das eine über das andere kopieren.

Wie kann dies geschehen, ohne eine Menge mysql-Befehle auszuführen? (Es fühlt sich an, als könnten sie umfallen, wenn sie nicht richtig überprüft werden!) Kann dies über Gulp’s (ich habe es erwähnt gesehen) oder ein Plugin erreicht werden?

Nur um das klarzustellen, ich spreche nicht davon, Daten über so etwas hin und her zu schieben/zu ziehen WP Migrieren Sie DB Pro, BackupBuddy oder etwas Ähnliches – dies ist eine Zusammenführung, nicht das Ersetzen einer Datenbank durch eine andere.

Ich würde gerne wissen, wie andere Entwickler das umgehen!

Dateiänderungen sind ziemlich einfach zu umgehen, es ist, wenn es Datenänderungen gibt, die den Albtraum verursachen.

WP Postkutsche führt eine Zusammenführung durch, aber Sie können nicht lokal arbeiten, es erstellt eine Staging-Site aus der Live-Site, an der Sie arbeiten sollen. Die Zusammenführung funktioniert großartig, aber es ist ein tödlicher Schlag, nicht lokal arbeiten zu können.

Das wurde mir auch von den Entwicklern gesagt datahawk.io wird tun, was ich will, aber es gibt kein Veröffentlichungsdatum dafür.

Es hört sich so an, als ob VersionPress das tun könnte, was Sie brauchen:

VersionPress-Staging

Ein paar Vorbehalte: Ich habe es nicht benutzt, kann also nicht für seine Wirksamkeit bürgen; und es befindet sich derzeit im Early Access.

Wichtig: Erstellen Sie eine Sicherungskopie der Live-Datenbank, bevor Sie lokale Daten damit zusammenführen.

Befolgen Sie diese Schritte, um den großen Prozentsatz an Daten zu migrieren und sie live zusammenzuführen

1. Gehen Sie zum wp-Back-End von Lokale Website Extras->Exportieren.
2. Optionsfeld Alle Inhalte auswählen (falls nicht standardmäßig ausgewählt).
3. Dadurch wird eine XML-Datei erstellt, die alle lokalen Daten enthält, die aus allen Standard-Post-Typen und benutzerdefinierten Post-Typen bestehen.
4. Öffnen Sie diese XML-Datei in Notepad++ oder einem beliebigen Editor und suchen und ersetzen Sie die lokale URL durch die Live-URL.
5. Besuchen Sie jetzt die Live-Site und importieren Sie das XML unter Tools->Import.
6. Laden Sie die Dateien (Bilder) manuell hoch.

Dadurch wird ein großer Prozentsatz der Daten von Local to Live übertragen.

Für die restlichen Daten müssen Sie benutzerdefinierte Skripte schreiben.

Risikofaktoren sind:

1. Beim Hochladen der Bilder von Local to Live werden gleichnamige Bilder überschrieben.
2. WordPress speichert die Bilder in post_meta und generiert serialisierte Daten für die Bilder, die beim Hochladen der Datenbank berücksichtigt werden sollten.
3. Serialisierte Daten in post_meta für post_type="attachment" speichert serialisierte Daten für 3 oder 4 Dimensionen der Bilder.
4. Benutzernamen oder E-Mail-IDs von Benutzern beim Importieren der Daten können gleich sein (oder wp führt die Funktion zum Überprüfen eindeutiger Benutzernamen und E-Mails aus), dann werden diese Benutzer nicht importiert (möglicherweise).

Wenn ich Sie wäre, würde ich Folgendes tun (langsam, aber bietet Ihnen die größten Erfolgschancen)

Richten Sie zunächst irgendwo eine dritte Datenbank ein. Cloud-Dienste wären wahrscheinlich ideal, da Sie für ein paar Stunden einen leistungsstarken Server mit einer SSD erhalten könnten. Sie werden diese Pferdestärken brauchen.

Zweitens werden wir mysqldump die erste DB und leiten Sie die Ausgabe in unsere Cloud-DB.

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

Jetzt haben wir eine vollständige Kopie von DB #1. Wenn Ihre Cloud Snapshots von Daten unterstützt, sollten Sie jetzt einen erstellen.

Der letzte Schritt besteht darin, ein PHP-Skript zu schreiben, das langsam aber sicher die Daten aus der zweiten DB auswählt und in die dritte schreibt. Wir wollen diese Platte nach der anderen machen. Wieso den? Nun, wir müssen die Beziehungen zwischen Datensätzen aufrechterhalten. Nehmen wir also Kommentare und Beiträge. Wenn wir Beitrag Nr. 1 aus DB Nr. 2 ziehen, kann er den Datensatz Nr. 1 nicht behalten, da DB Nr. 1 bereits einen hatte. Aus Beitrag Nr. 1 wird also Beitrag Nr. 132. Das bedeutet, dass alle Kommentare für Beitrag Nr. 1 jetzt als zu Beitrag Nr. 132 gehörend geschrieben werden müssen. Sie müssen auch die Datensätze für die Benutzer abrufen, die diese Beiträge erstellt haben, da sich auch ihre Benutzer-IDs ändern.

Dafür gibt es keine einfache Lösung, aber die WP-Struktur ist nicht besonders komplex. Das Erstellen einer einfachen Schleife, um die Daten abzurufen und zu übersetzen, sollte nicht mehr als ein paar Stunden Arbeit sein.

Wenn ich Sie verstehe, um lokale und Live-Datenbank zusammenzuführen, verwende ich bis jetzt andere Software wie z NavicatPremiumes hat die Datensynchronisationsfunktion.

Dies kann live mit spring-xd erreicht werden, erstellen Sie einen JDBC-Stream, um Daten aus einer Datenbank zu ziehen und in die andere einzufügen. (Dies fungiert als Streaming, sodass Sie keine Umgebung stören müssen.)

Als Erstes müssen Sie prüfen, ob es einfacher wäre, anstelle eines Migrationsskripts eine Dateneingabe durch Kopieren und Einfügen vorzunehmen. Manchmal ist die beste Antwort, es aufzusaugen und es manuell über die CMS-Oberfläche zu tun. Dies vermeidet potenzielle Konflikte beim Zusammenführen von Primärschlüsseln, aber Sie müssen möglicherweise auf Referenzen wie den Ersteller eines Beitrags oder ähnliche Daten achten.

Wenn es einfach zu viel ist, manuell zu migrieren, stecken Sie damit fest, ein Skript zu schreiben oder eines zu finden, das bereits für Sie geschrieben wurde. Angenommen, da draußen ist nichts, hier ist, was Sie tun …

MACHEN SIE IMMER EINE SICHERUNG, BEVOR SIE MIGRATIONEN AUSFÜHREN!

1) Erstellen Sie eine Liste dessen, was Sie übertragen müssen. Benötigen Sie Benutzer, Beiträge usw.? Suchen Sie die Datenbanktabellen und fügen Sie sie der Liste hinzu.

2) Notieren Sie sich alles Mögliche fremde Schlüssel in den Datenbanktabellen, die in die neue Datenbank zusammengeführt werden. Zum Beispiel, wp_posts hat post_author referenzieren wp_users. Diese müssen während der Migration besonders beachtet werden. Benutze das Dokumentation zu helfen, sie zu finden.

3) Sobald Sie wissen, welche Tabellen Sie benötigen und worauf sie verweisen, müssen Sie das Skript schreiben. Beginnen Sie damit, herauszufinden, was Inhalt ist Neu für die andere Datenbank. Der sicherste Weg ist, dies manuell mit einer Art Side-by-Side-Liste zu tun. Sie können sich jedoch Ihre eigenen Regeln ausdenken, wie Tabellenzeilen automatisch abgeglichen werden. Vielleicht zur Kontrolle $post1->post_content === $post2->post_content in Fällen, in denen der Text gleich sein muss. Der einzige Haken hier ist, dass die Primär-/Fremdschlüssel für diese Regeln tabu sind.

4) Wie fusioniert man Neu Inhalt? Die allgemeine Idee ist, dass alle Primärschlüssel für jeden neuen Inhalt geändert werden müssen. Sie möchten alles außer der ID von post verwenden und diese in die neue Datenbank einfügen. Es wird ein automatisches Inkrement geben, um die neue ID zu erstellen, sodass Sie die vorherige ID nicht benötigen (es sei denn, Sie möchten sie für die Skriptausgabe/das Debuggen).

5) Der knifflige Teil ist der Umgang mit den Fremdschlüsseln. Dieser Prozess wird stark variieren, je nachdem, was Sie migrieren möchten. Was Sie wissen müssen, ist, welcher Fremdschlüssel zu welchem ​​(möglicherweise neuen) Primärschlüssel gehört. Wenn Sie nur Posts migrieren, müssen Sie möglicherweise eine Benutzer-ID-zu-Benutzer-ID-Zuordnung für die fest codieren post_author Spalte, dann verwenden Sie diese, um die Werte zu ersetzen.

Was aber, wenn ich die Benutzer-IDs für die Zuordnung nicht kenne, weil einige Benutzer ebenfalls migriert werden müssen?

Hier wird es knifflig. Sie müssen zuerst die Zusammenführungsregeln definieren, um zu sehen, ob ein Benutzer bereits vorhanden ist. Zum Neu Benutzer müssen Sie die ID der neu eingefügten Benutzer aufzeichnen. Nachdem alle Benutzer migriert wurden, wird die post_author Der Wert muss ersetzt werden, wenn er auf einen neu zusammengeführten Benutzer verweist.

6) Schreiben und testen Sie das Skript! Testen Sie es zuerst auf Dummy-Datenbanken. Und wieder, Machen Sie Backups, bevor Sie es auf Ihren Datenbanken verwenden!

Ich habe etwas ähnliches mit gemacht ETL-Prozess (Extrahieren, Transformieren, Laden). als ich Daten von einem CMS auf ein anderes verschoben habe.

Anstatt ein Skript zu schreiben, habe ich a verwendet Pentaho Data Integration (Kettle)-Tool.

Die Idee von ETL ist ziemlich einfach:

• EExtrahieren der Daten (z. B. aus einer Datenbank)
• TErweitern Sie es, um es Ihren Bedürfnissen anzupassen
• LLaden Sie es an das endgültige Ziel (Ihre zweite Datenbank).

Das Tool ist einfach zu bedienen und ermöglicht es Ihnen, mit verschiedenen Schritten und Ausgaben zu experimentieren, um die Daten zu untersuchen. Wenn Sie einen richtigen ETL-Prozess entwerfen, sind Sie bereit, Ihre Datenbanken zusammenzuführen.