Синхронизация базы данных WordPress между Dev и Prod


19

Ранее задавался вопрос о том, как синхронизировать файлы и базу данных между двумя установками Wordpress.

Для уровня базы данных ответ обычно состоит в том, чтобы в основном сбросить одну базу данных и вставить ее на другой сервер. Проблема в том, что вы теряете любые изменения, которые могли быть внесены на сервере prod. Например, показатели использования, комментарии и т. Д.

Имея это в виду, я начинал задаваться вопросом, можно ли будет расширить ORM в Wordpress, чтобы вы могли генерировать дельты и затем вводить их в сайт prod.

Кто-нибудь пробовал это, изучал или у вас есть идеи или комментарии?


1
Я изучил это, да, но не достиг многого. Если бы вы могли указать на подтверждение концепции с другой платформой CMS, я уверен, что мы могли бы перенастроить ее для WordPress.
EAMann

Как насчет репликации?
Ковшенин

Ну, для репликации с mysql потребуется некоторая форма репликации мастер-мастер, которая является PITA. Если учесть тот факт, что это между dev и prod, то репликацию придется отложить, что, скорее всего, будет все время прерываться.
Джонатансерафини

Ответы:


11

Реальность такова, что мы хотим, чтобы это было: http://www.liquibase.org/

Liquibase - это библиотека с открытым исходным кодом (Apache 2.0 Licensed), независимая от базы данных, для отслеживания, управления и применения изменений в базе данных. Он основан на простом предположении: все изменения в базе данных хранятся в удобочитаемой, но отслеживаемой форме и проверяются в системе контроля версий.

Однако наш процесс разработки не поддерживает это. Обычно мы не изменяем базу данных с помощью отдельных скриптов, которые мы пишем сами, мы используем подключаемые модули. Мы не пишем сценарии DML для изменения справочных данных, которые мы затем проверяем в управлении исходным кодом, мы используем пользовательский интерфейс на странице администратора и поэтому не имеем исходного кода для последующего использования при репликации этого изменения во время миграции.

Однако мы можем подражать некоторым из них - используя некоторые из инструментов, перечисленных на этой странице:

/programming//q/225772/149060

Например, жидкая база имеет отличительную особенность, которая также, необязательно, включает изменения в данных. Мы могли бы потенциально вывести схему и разность данных в сценарий, исключив (насколько это возможно) определенные таблицы, которые могут включать тестовые данные (например, опубликовать и т. Д.), А затем применить сценарий к производственной базе данных.

MySQLDiff (обсуждаемый в вопросе StackOverflow) выполняет различие схемы, и его автор рекомендует mysql_coldiff для различий в табличных данных - оба они реализованы в perl, если инструменты java (liquidbase) слишком загружены для ваших серверов - хотя обе базы данных локальны и запуск инструмента на вашем ПК решает эту проблему ...

Если мы действительно хотим сделать это правильно, мы должны зарегистрировать любой sql, связанный с настройками, опциями или другими изменениями конфигурации, а также с любыми изменениями схемы - и преобразовать зарегистрированный код в сценарий миграции для игры с нашим рабочим сервером. Воспроизведите сценарий миграции с сервера, скопируйте файлы сайта WordPress (исключая загрузки, если применимо), и мы станем золотыми.

Таким образом, мне кажется, что лучшим выходом является плагин разработчика-разработчика-миграции, который перехватывает SQL-файл, который нам нужен, сохраняет его и затем генерирует сценарий миграции из зарегистрированного кода, а не для создания способа объединения баз данных. между постановкой и производством. Кажется, проще решить проблему.

Если мы посмотрим на код инструментального крюка @bueltge, то плагин вызывает плагин для вдохновения: https://gist.github.com/1000143 (спасибо Рону Реннику через G + за указание мне в направлении SAVEQUERIES и крюку отключения, что ведите меня, чтобы найти его)

- измените его, чтобы получить вывод SAVEQUERIES вместо 
- запускать только в режиме администратора 
- отфильтровать все выбранные 
- сохранить результаты в таблице в хук отключения 
- мы могли бы выборочно переключать ловушку на основе того, что мы делали в данный момент.  

Например:

Имя захвата: активировать и настроить плагин XYZ

Переключение состояния захвата - на

... установить и настроить плагин XYZ

Переключение состояния захвата - выкл.

Экспорт сценария миграции для: активировать и настроить плагин XYZ

Нажмите кнопку «Экспорт» - чтобы создать всплывающее текстовое поле с отфильтрованным захваченным SQL-кодом - в идеале предварительно отформатированный как сценарий оболочки с вызовом mysql из командной строки. Скопируйте и вставьте его в папку с кодом миграции и добавьте в хранилище исходного кода.

Будьте внимательны, чтобы включать и выключать захват во время работы, и вы сможете сгенерировать идеальный сценарий миграции, чтобы перенести вашу производственную базу данных в эквивалентную конфигурацию с вашей промежуточной базой данных.

Что еще лучше, у вас будет сценарий (или серия таких же), которые вы можете проверить. Imaging с воспроизводимыми, тестируемыми, сценариями миграции !!

Я уже влюблен.

Кто-нибудь еще?


2
Хорошая рецензия. Я тратил много времени на эту проблему, потому что у меня есть клиенты, которые ищут нашей помощи. Это действительно сложная проблема, но мы решили, что переход на уровень SQL, вероятно, является слишком сложным решением «вскипятить океан», то есть шансы заставить его работать на 100% маловероятны. Я думаю, что решение состоит в том, чтобы использовать подход «разделяй и властвуй» с явным кодом, который понимает структуру WordPress и обеспечивает ловушки для всего остального. Я надеюсь, что мы сможем представить жизнеспособное решение публично в какой-то момент в будущем.
MikeSchinkel

Итак .... кто хочет сделать это?
Дэйв Кисс

для тех, кто ищет, кажется, эта же идея доступна в виде плагина: wordpress.org/plugins/query-recorder
majick

3

База данных синхронизации WordPress плагин делает большую работу по синхронизации данных между двумя серверами.

По умолчанию он перезаписывает ВСЕ данные назначения, однако я только что добавил некоторые улучшения в плагин, которые позволяют синхронизировать только определенные таблицы базы данных. Это может помочь вам сохранить комментарии, пользователей и другие данные, которые вы не хотите перезаписывать. Это дает вам гранулярность, которая вам нужна?

Я еще не опубликовал свои изменения для широкой публики, но если вы заинтересованы в копии, отправьте мне электронное письмо на simon-at-yump.com.au. Если кто-то посчитает это полезным или у него есть дополнительные запросы, дайте мне знать, и я посмотрю, что я могу сделать.


ОБНОВЛЕНИЕ: Я также только что нашел плагин WP-Sync-DB , который является вилкой коммерческого плагина WP-Migrate-DB-Pro . Это делает очень похожую вещь, хотя, вероятно, имеет больше полировки, чем синхронизация базы данных .


0

Специально для этой задачи существует относительно новый коммерческий сервис. Это называется RAMP:

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


1
У этой службы есть ограничения, из-за которых она не подходит для моего
варианта

2
Мой вариант использования - добавление функциональности, в то время как производство добавляет контент. Цитата: «Следующие элементы в настоящее время не поддерживаются: Настройки (настройки ядра и плагина, если они не подключены к RAMP)» 99,99% параметров и настроек темы и плагина не будут перенесены. Без изменений кода на производстве пользовательские типы постов не будут мигрировать. Забудьте о добавлении пользовательских таблиц и их данных.
marfarma

1
У этого продукта есть действительный сценарий использования - постановка контента, а затем его запуск. К сожалению, это не проблема, с которой я связан. Возвращаясь к OP, неясно, с каким вариантом использования он имеет дело - так что это может быть идеальным решением для их магазина.
marfarma
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.