Как объединить локальные и живые базы данных?

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

Итак, я говорю о том, что локальная версия сайта, где файлы и данные изменены, в то время как данные на реальном сайте также меняются одновременно.

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

Как это можно сделать, если не выполнить тонну команд mysql? (кажется, что они могут упасть, если их не проверили должным образом!) Можно ли это сделать через Gulp (я видел, как он упоминается) или плагин?

Просто для того, чтобы быть ясным, я не говорю о том, чтобы выталкивать/вытягивать данные туда и обратно с помощью WP Migrate DB Pro, BackupBuddy или что-то подобное - это слияние, не заменяя одну базу данных на другую.

Мне бы хотелось узнать, как другие разработчики обошли это!

Изменения файла довольно просты в обращении, когда при изменении данных происходит кошмар.

WP Stagecoach делает слияние, но вы не можете работать локально, он создает промежуточный сайт с сайта, на котором вы должны работать. Слияние отлично работает, но это убийственный удар, чтобы не работать на месте.

Мне также сказали разработчики, что datahawk.io будет делать то, что я хочу, но там нет даты выпуска.

ОТВЕТЫ

Ответ 1

Похоже, что VersionPress может делать то, что вам нужно:

Постановка в формате VersionPress

Несколько предостережений: я не использовал его, поэтому не могу ручаться за его эффективность; и в настоящее время он находится на раннем доступе.

Ответ 2

Важно: сделайте резервную копию Live-базы данных до слияния локальных данных с ней.

Выполните следующие шаги, чтобы помочь в переносе большого процента данных и слиянии с ним в режиме реального времени

  • Перейдите в wp back-end Локальный сайт Инструменты- > Экспорт.
  • Выберите переключатель Все содержимое (если он не выбран по умолчанию).
  • Это приведет к созданию файла Xml, содержащего все локальные данные, состоящие из всех типов сообщений по умолчанию и пользовательских типов сообщений.
  • Откройте этот XML файл в блокноте ++ или любом редакторе и найдите и замените локальный URL с помощью Live URL.
  • Теперь посетите сайт Live и импортируйте XML в Инструменты → Импорт.
  • Загрузите файлы (изображения) вручную.

Это приведет к большому проценту данных из Local to Live.

Остальные данные, которые вы должны будете написать для собственных скриптов.

Факторы риска:

  • При загрузке изображений из Local в Live изображения с одинаковыми именами будет превзойден.
  • Wordpress сохраняет изображения в post_meta, генерируя сериализованные данные для изображений, чем следует учитывать при загрузке базы данных.
  • Сериализованные данные в post_meta для post_type="attachment" сохраняют сериализованные данные для 3 или 4 размеров изображений.
  • Имена пользователей или идентификаторы электронной почты пользователей при импорте данных могут быть одинаковыми (или wp выполняет функцию проверки уникальных имен пользователей и электронной почты), тогда эти пользователи не будут импортированы (возможно, будут возможны).

Ответ 3

Если бы я был вами, я бы сделал следующее (медленное, но дающее вам наибольшие шансы на успех)

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

Во-вторых, мы отправимся в mysqldump первую БД и выведем вывод в нашу облачную БД.

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

Теперь у нас есть полная копия DB # 1. Если ваше облако поддерживает моментальные снимки, обязательно возьмите их.

Последний шаг - написать PHP script, который медленно, но верно выбирает данные из второго БД и записывает его в третью. Мы хотим сделать эту запись за раз. Зачем? Ну, нам нужно поддерживать отношения между записями. Поэтому давайте примем комментарии и сообщения. Когда мы вытаскиваем пост №1 из БД # 2, он не сможет сохранить запись №1, потому что в БД №1 уже есть один. Итак, теперь пост №1 становится пост № 132. Это означает, что все комментарии к сообщению # 1 теперь должны быть записаны как принадлежащие к сообщению # 132. Вам также придется извлекать записи для пользователей, которые сделали эти сообщения, потому что их идентификаторы пользователей также будут изменены.

Там нет легкого исправления, но структура WP не очень сложна. Построение простого цикла, чтобы вытащить данные и перевести их, должно быть не более двух часов работы.

Ответ 4

Если я понимаю вас, чтобы объединить локальную и живую базу данных, до сих пор я использую другое программное обеспечение, такое как NavicatPremium, у него есть функция Data Sycn.

Ответ 5

Это может быть достигнуто в реальном времени с помощью spring -xd, создать поток JDBC для извлечения данных из одного db и вставки в другой. (Это действует как потоковая передача, поэтому вам не нужно беспокоить окружающую среду)

Ответ 6

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

Если это просто слишком много для ручной миграции, вы застряли в написании script или поиске того, что уже написано для вас. Предполагая, что там ничего нет, вот что вы делаете...

ВСЕГДА СДЕЛАЙТЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ ПЕРЕД ПЕРЕМЕЩЕНИЕМ МИГРАЦИЙ!

1) Составьте список того, что вам нужно передать. Вам нужны пользователи, сообщения и т.д.? Найдите таблицы базы данных и добавьте их в список.

2) Запишите все возможные внешние ключи в таблицах базы данных, которые будут объединены в новую базу данных. Например, wp_posts имеет post_author, ссылающийся на wp_users. Это потребует особого внимания во время миграции. Используйте документацию, чтобы найти их.

3) Как только вы узнаете, какие таблицы вам нужны и что они ссылаются, вам нужно написать script. Начните с выяснения, какой контент является новым для другой базы данных. Самый безопасный способ - сделать это вручную с помощью своего рода бок о бок. Однако вы можете придумать свои правила о том, как автоматически сопоставлять строки таблицы. Возможно, для проверки $post1->post_content === $post2->post_content в тех случаях, когда текст должен быть одним и тем же. Единственный улов здесь - это первичные/внешние ключи, которые не соответствуют этим правилам.

4) Как вы объедините новый контент? Общая идея заключается в том, что все первичные ключи необходимо будет изменить для любого нового контента. Вы хотите использовать все, кроме идентификатора сообщения, и вставлять его в новую базу данных. Будет создан автоматический инкремент для создания нового идентификатора, поэтому вам не понадобится предыдущий идентификатор (если вы не хотите его для script вывода/отладки).

5) Сложная часть - обработка внешних ключей. Этот процесс будет сильно отличаться в зависимости от того, что вы планируете переносить. Что вам нужно знать, какой внешний ключ попадает на какой (возможно, новый) первичный ключ. Если вы только переносите сообщения, вам может потребоваться жестко указать идентификатор пользователя для сопоставления идентификатора пользователя для столбца post_author, а затем использовать его для замены значений.

Но что, если я не знаю идентификаторы пользователя для сопоставления, потому что некоторые пользователи также должны быть перенесены?

Здесь сложно. Вам нужно будет сначала определить правила слияния, чтобы убедиться, что пользователь уже существует. Для новых пользователей вам необходимо записать идентификатор вновь вставленных пользователей. Затем, после переноса всех пользователей, значение post_author должно быть заменено, когда оно ссылается на вновь объединенного пользователя.

6) Напишите и протестируйте script! Сначала проверьте его на фиктивных базах данных. И снова создайте резервные копии, прежде чем использовать их в своих базах данных!

Ответ 7

Я сделал что-то simillar с процесс ETL (Извлечь, Преобразовать, Загрузить), когда я перемещал данные с одной CMS на другую.

Вместо записи script я использовал инструмент Pentaho Data Integration (Kettle).

Идея ETL довольно проста:

  • E. Извлечь данные (например, из одной базы данных).
  • T преобразует его в соответствии с вашими потребностями.
  • L до конечного пункта назначения (вторая база данных).

Инструмент прост в использовании и позволяет вам экспериментировать с различными шагами и выходами для исследования данных. Когда вы разрабатываете правильные ETL-процессы, вы готовы объединить свои базы данных.

Ответ 8

Как это можно сделать без запуска команд mysql?

Ни в коем случае. Если одновременно работают как локальные, так и веб-сайты, как вы можете предотвратить отсутствие одинаковых идентификаторов с различным контентом?

Ответ 9

поэтому, если вы хотите сделать это, вы можете использовать mysql repication.i, подумайте, что это поможет вам объединиться с другой базой данных mysql.