Synchronizacja bazy danych Wordpress między dev i prod

Pytanie zostało wcześniej zadane na temat synchronizacji plików oraz bazy danych między dwiema instalacjami Wordpress.

Na poziomie bazy danych odpowiedzią jest zazwyczaj zrzucenie jednej bazy danych i wstawienie jej na inny serwer. Problem polega na tym, że tracisz wszelkie zmiany, które potencjalnie zostały wprowadzone na serwerze prod. Na przykład wskaźniki użytkowania, komentarze itp.

Mając to na uwadze, zacząłem się zastanawiać, czy można rozszerzyć Wordpress ORM, aby można było generować delty, a następnie wstrzykiwać je do strony prod.

Czy ktoś próbował tego, przyglądając się temu, lub miał jakieś pomysły lub komentarze?

W rzeczywistości chcemy tego: http://www.liquibase.org/

Liquibase to otwarta biblioteka (licencjonowana Apache 2.0), niezależna od bazy danych biblioteka do śledzenia, zarządzania i stosowania zmian w bazie danych. Opiera się na prostej przesłance: wszystkie zmiany w bazie danych są przechowywane w czytelnej dla człowieka, ale możliwej do śledzenia formie i sprawdzane pod kontrolą źródła.

Jednak nasz proces rozwoju tego nie obsługuje. Zazwyczaj nie modyfikujemy bazy danych za pomocą dyskretnych skryptów, które sami piszemy, korzystamy z aktywowanych przez nas wtyczek. Nie piszemy skryptów DML do modyfikowania danych wyszukiwania, które następnie sprawdzamy w celu kontroli kodu źródłowego, używamy interfejsu użytkownika na stronie administratora i dlatego nie mamy kodu źródłowego do późniejszego wykorzystania w replikacji tej zmiany podczas migracji.

Możemy jednak naśladować niektóre z nich - korzystając z niektórych narzędzi wymienionych na tej stronie:

/programming//q/225772/149060

Na przykład baza cieczy ma funkcję różnicowania, która również opcjonalnie obejmuje zmiany danych. Możemy potencjalnie wyprowadzić schemat i różnicę danych do skryptu, wykluczając (jak to możliwe) niektóre tabele, które mogą zawierać dane testowe (tj. Post itp.), A następnie zastosować skrypt do produkcyjnej bazy danych.

MySQLDiff (omówione w pytaniu StackOverflow) ma różnice w schemacie i jego autor zaleca mysql_coldiff w przypadku różnic danych w tabelach - oba są implementowane w perlu, jeśli narzędzia Java (baza płynów) są zbyt obciążające zasoby dla twoich serwerów - chociaż przenieś obie bazy danych lokalnie a uruchomienie narzędzia na komputerze rozwiązuje ten problem ...

Jeśli naprawdę chcemy to zrobić poprawnie, powinniśmy zarejestrować każdy kod SQL związany z ustawieniami, opcjami lub innymi zmianami konfiguracji i wszelkimi zmianami schematu - i przekonwertować zarejestrowany kod na skrypt migracji, aby grać na naszym serwerze produkcyjnym. Zagraj w skrypt migracji na serwerze, skopiuj pliki strony wordpress (z wyłączeniem przesyłania, jeśli dotyczy), a my będziemy złota.

Wydaje mi się więc, że najlepszym wyjściem jest wtyczka do tworzenia i migracji programów deweloperskich, która przechwytuje potrzebną sql, przechowuje ją, a następnie generuje skrypt migracji z zarejestrowanego kodu, zamiast budować sposób na połączenie baz danych między inscenizacją a produkcją. Wydaje się również, że problem jest prostszy do rozwiązania.

Jeśli spojrzymy na kod wtyczki przywoławczej @bueltge, wtyczka wywołuje inspirację: https://gist.github.com/1000143 (dzięki Ronowi Rennickowi za pośrednictwem G + za skierowanie mnie w stronę SAVEQUERIES i haka zamykającego, to poprowadź mnie do znalezienia)

- zmień go, aby otrzymać wyjście SAVEQUERIES 
- uruchamiaj tylko będąc w adminie 
- odfiltruj wszystkie wybrane 
- zapisać wyniki na stole w haku zamykającym 
- możemy selektywnie przełączać pułapki wyjściowe w oparciu o to, co robiliśmy w tej chwili.  

Na przykład:

Nazwa przechwytywania: Aktywuj i skonfiguruj wtyczkę XYZ

Włącz przechwytywanie stanu

... zainstaluj i skonfiguruj wtyczkę XYZ

Capture State Toggle - off

Eksportuj skrypt migracji dla: Aktywuj i skonfiguruj wtyczkę XYZ

Naciśnij przycisk Eksportuj - aby wyświetlić wyskakujące pole tekstowe z filtrowanym SQL w pułapce - najlepiej wstępnie sformatowane jako skrypt powłoki z wywołaniem wiersza polecenia do mysql. Skopiuj i wklej go do folderu kodu migracji i dodaj do repozytorium kodu źródłowego.

Uważaj na włączanie i wyłączanie przechwytywania podczas pracy, a będziesz w stanie wygenerować idealny skrypt migracji, aby przenieść produkcyjną bazę danych do konfiguracji równoważnej z bazą danych pomostowych.

Co więcej, będziesz mieć skrypt (lub serię takich samych), który możesz TESTOWAĆ. Obrazowanie z powtarzalnymi, testowalnymi skryptami migracyjnymi !!

Jestem już zakochany.

Ktoś jeszcze?

Database Sync WordPress plugin robi wielkie zadanie synchronizacji danych pomiędzy dwoma serwerami.

Domyślnie zastępuje WSZYSTKIE dane docelowe, jednak właśnie zaimplementowałem pewne ulepszenia wtyczki, które pozwalają synchronizować tylko określone tabele bazy danych. Pomoże to zachować komentarze, użytkowników i inne dane, których nie chcesz zastępować. Czy to zapewnia Ci szczegółowość, której potrzebujesz?

Nie opublikowałem jeszcze swoich zmian, ale jeśli jesteś zainteresowany kopią, wyślij mi e-mail na stronie simon-at-yump.com.au. Jeśli ktoś uzna to za przydatne lub ma dodatkowe prośby o funkcje, daj mi znać, a zobaczę, co mogę zrobić.

AKTUALIZACJA: Właśnie znalazłem wtyczkę WP-Sync-DB , która jest rozwidleniem komercyjnej wtyczki WP-Migrate-DB-Pro . Robi to bardzo podobnie, chociaż prawdopodobnie ma więcej szlifowania niż synchronizacja bazy danych .

Istnieje specjalnie nowa usługa komercyjna specjalnie do tego zadania. Nazywa się RAMP:

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