Wordpress-Datenbanksynchronisation zwischen dev und prod


19

Es wurde bereits eine Frage zum Synchronisieren von Dateien und der Datenbank zwischen zwei Wordpress-Installationen gestellt.

Auf Datenbankebene lautet die Antwort in der Regel, eine Datenbank zu sichern und auf einem anderen Server einzufügen. Das Problem dabei ist, dass Sie am Ende alle Änderungen verlieren, die möglicherweise auf dem Prod-Server vorgenommen wurden. Zum Beispiel Nutzungsmetriken, Kommentare usw.

Vor diesem Hintergrund begann ich mich zu fragen, ob es möglich sein würde, den Wordpress-ORM so zu erweitern, dass Sie Deltas generieren und diese dann in die Prod-Site injizieren können.

Hat jemand dies ausprobiert, sich damit befasst oder hat er Ideen oder Kommentare?


1
Ich habe es mir angeschaut, aber nicht viel erreicht. Wenn Sie mit einer anderen CMS-Plattform auf einen Proof-of-Concept verweisen könnten, könnten wir ihn sicher für WordPress neu auslösen.
EAMann,

Wie wäre es mit Replikation?
Kovshenin

Nun, die Replikation mit MySQL würde eine Art Master-Master-Replikation erfordern, die eine PITA ist. Wenn Sie die Tatsache berücksichtigen, dass dies zwischen dev und prod liegt, müsste die Replikation verzögert werden, was höchstwahrscheinlich die ganze Zeit zum Erliegen kommen würde.
Jonathanserafini

Antworten:


11

Die Realität sieht so aus: http://www.liquibase.org/

Liquibase ist eine datenbankunabhängige Open Source-Bibliothek (Apache 2.0 Licensed) zum Nachverfolgen, Verwalten und Anwenden von Datenbankänderungen. Es basiert auf einer einfachen Prämisse: Alle Datenbankänderungen werden in einer für den Menschen lesbaren und dennoch verfolgbaren Form gespeichert und in die Quellcodeverwaltung eingecheckt.

Unser Entwicklungsprozess unterstützt dies jedoch nicht. Normalerweise ändern wir die Datenbank nicht über eigens erstellte Skripte, sondern verwenden Plugins, die wir aktivieren. Wir schreiben keine DML-Skripte, um Suchdaten zu ändern, die wir dann in die Quellcodeverwaltung einchecken. Wir verwenden eine Benutzeroberfläche auf der Administrationsseite und haben daher keinen Quellcode für die spätere Verwendung beim Replizieren dieser Änderung während der Migration.

Wir können jedoch einige davon emulieren, indem wir einige der auf dieser Seite aufgelisteten Tools verwenden:

/programming//q/225772/149060

Beispielsweise verfügt liquidbase über eine Diff-Funktion, die optional auch Änderungen an Daten enthält. Möglicherweise können wir das Schema und den Datenunterschied in einem Skript ausgeben, wobei (soweit möglich) bestimmte Tabellen ausgeschlossen werden, die Testdaten enthalten (z. B. nachträglich usw.), und dann das Skript auf die Produktionsdatenbank anwenden.

MySQLDiff (auf der StackOverflow-Frage besprochen) führt Schemaunterschiede durch, und sein Autor empfiehlt mysql_coldiff für tabellenweise Datenunterschiede - beide sind in Perl implementiert, wenn Java-Tools (liquidbase) für Ihre Server zu ressourcenintensiv sind - obwohl beide Datenbanken lokal sind und das Ausführen des Tools auf Ihrem PC löst dieses Problem ...

Wenn wir es wirklich richtig machen wollen, sollten wir alle SQL-Anweisungen protokollieren, die sich auf Einstellungen, Optionen oder andere Konfigurationsänderungen sowie auf Schemaänderungen beziehen - und den protokollierten Code in ein Migrationsskript konvertieren, um gegen unseren Produktionsserver zu spielen. Spielen Sie das Migrationsskript gegen den Server, kopieren Sie die WordPress-Site-Dateien (ggf. ohne Uploads) und wir sind goldrichtig.

Daher scheint es mir, dass der beste Ausweg das Migrations-Builder-Plugin eines Entwicklers ist, das den von uns benötigten SQL-Code abfängt, speichert und dann ein Migrationsskript aus dem protokollierten Code generiert, anstatt eine Möglichkeit zum Zusammenführen von Datenbanken zu erstellen zwischen Inszenierung und Produktion. Scheint auch ein einfacheres Problem zu lösen.

Wenn wir uns den Code des Instrumenting Hooks von @bueltge ansehen, rufen wir das Plugin zur Inspiration auf: https://gist.github.com/1000143 (danke an Ron Rennick über G +, der mich in Richtung SAVEQUERIES und Shutdown Hook geführt hat) führe mich, es zu finden)

- Ändern Sie es, um stattdessen die SAVEQUERIES-Ausgabe zu erhalten 
- Nur im Admin-Modus ausführen 
- Alle Auswahlen herausfiltern 
- Ergebnisse im Shutdown Hook abspeichern 
- Wir konnten die Ausgabe-Überfüllung basierend auf dem, was wir gerade machten, selektiv umschalten.  

Beispielsweise:

Capture Name: Aktiviere und konfiguriere das Plugin XYZ

Capture State Toggle - Ein

... Plugin XYZ installieren und konfigurieren

Capture State Toggle - aus

Export Migrationsskript für: Plugin XYZ aktivieren & konfigurieren

Drücken Sie die Export-Taste, um ein Popup-Textfeld mit dem gefilterten SQL-Code zu erstellen. Idealerweise ist es als Shell-Skript mit Befehlszeilenaufruf an mysql vorformatiert. Kopieren Sie es in Ihren Migrationscode-Ordner und fügen Sie es Ihrem Quellcode-Repository hinzu.

Wenn Sie die Erfassung während der Arbeit ein- und ausschalten, können Sie das perfekte Migrationsskript generieren, um Ihre Produktionsdatenbank in eine der Staging-Datenbank entsprechende Konfiguration zu bringen.

Was ist besser, haben Sie ein Skript (oder eine Reihe von gleichen), die Sie testen können. Imaging mit replizierbaren, testbaren Migrationsskripten !!

Ich bin schon verliebt.

Irgendjemand anderes?


2
Nizza schreiben. Ich habe viel Zeit mit diesem Problem verbracht, weil ich Kunden habe, die unsere Hilfe suchen. Es ist ein wirklich schweres Problem, aber wir haben entschieden, dass das Herunterschalten auf die SQL-Ebene wahrscheinlich zu viel für eine "Boil the Ocean" -Lösung ist, was bedeutet, dass die Wahrscheinlichkeit, dass es zu 100% funktioniert, unwahrscheinlich ist. Ich denke, die Lösung ist ein "Divide-and-Conquer" -Ansatz mit explizitem Code, der die Struktur von WordPress versteht und Hooks für alles andere bietet. Ich hoffe, wir können irgendwann in der Zukunft eine tragfähige Lösung öffentlich vorstellen.
MikeSchinkel

Also ... wer will das machen?
Dave Kiss

für alle, die suchen, scheint dieselbe idee als plugin verfügbar zu sein: wordpress.org/plugins/query-recorder
majick

3

Das Database Sync WordPress-Plugin erledigt eine großartige Aufgabe, um Daten zwischen zwei Servern zu synchronisieren.

Standardmäßig werden ALLE Zieldaten überschrieben, es wurden jedoch einige Verbesserungen am Plugin vorgenommen, mit denen Sie nur bestimmte Datenbanktabellen synchronisieren können. Dies kann Ihnen helfen, Kommentare, Benutzer und andere solche Daten, die Sie nicht überschreiben möchten, beizubehalten. Gibt Ihnen das die Granularität, die Sie benötigen?

Ich habe meine Änderungen noch nicht veröffentlicht, aber wenn Sie an einer Kopie interessiert sind, senden Sie mir eine E-Mail an simon-at-yump.com.au. Wenn jemand dies nützlich findet oder zusätzliche Funktionsanforderungen hat, lass es mich wissen und ich werde sehen, was ich tun kann.


UPDATE: Ich habe auch gerade das WP-Sync-DB- Plugin gefunden, eine Abzweigung des kommerziellen WP-Migrate-DB-Pro- Plugins. Es macht eine sehr ähnliche Sache, obwohl es wahrscheinlich mehr Polnisch als Database Sync hat .


0

Speziell für diese Aufgabe gibt es einen relativ neuen kommerziellen Dienst. Es heißt RAMP:

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


1
Es gibt Einschränkungen für diesen Dienst, die es nicht zu meinem Anwendungsfall machen:
Marfarma

2
Mein Anwendungsfall - Hinzufügen von Funktionen, während die Produktion Inhalte hinzufügt. Quote: "Die folgenden Elemente werden derzeit nicht unterstützt: Einstellungen (Kern- und Plugin-Einstellungen, sofern sie sich nicht für RAMP entscheiden)" 99,99% der Design- und Plugin-Optionen und -Einstellungen werden nicht migriert. Ohne Codeänderungen in der Produktion werden benutzerdefinierte Post-Typen nicht migriert. Vergessen Sie das Hinzufügen benutzerdefinierter Tabellen und ihrer Daten.
Marfarma

1
Dieses Produkt hat einen gültigen Anwendungsfall: Inhalte bereitstellen und dann live übertragen. Leider ist das nicht das Problem, mit dem ich mich befasse. Rückblickend auf das OP ist unklar, um welchen Anwendungsfall es sich handelt - daher könnte es die perfekte Lösung für ihren Shop sein.
Marfarma
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.