Skip to content

Синхронизация Drupal-сайтов с помощью migraine

24/11/2009


Синхронизация developement и production серверов в Drupal — занятие нелёгкое. Даже в 6 версии не хватает простого способа переноса и восстановления контента. В модуле CCK есть нужный функционал, но одним custom-контентом сайт обычно не ограничивается. Код модулей и ядра можно синхронизировать с помощью систем контроля версий, но что делать с базой?

На этот счёт есть разные подходы — начиная от обновления контента руками (годится для сайтов где контента немного) до дампа+восстановления всей базы целиком. Последний способ хорош, когда большой сайт надо отзеркалить 1 в 1. Но что если нам надо только перенести контент (созданные ноды, словари, alias’ы, таблицы с контентом модулей) при этом оставив конфигурацию прежней? Например, мы пробуем различные конфигурации на dev-сервере, и хотим синхронизировать контент с production-сервером. При полном дампе наши настройки будут просто перезаписаны настройками с сервера. А если нам надо перенести изменённую и протестированную конфигурацию с developement на production?

Для этих целей в компании Shearer Software был написан migraine — небольшой python-скрипт. Он отдельно синхронизирует контент и конфигурацию, умеет находить diff-ом несоответствия в структуре таблиц и сам разбирается с таблицами, в которые данные должны вставляться инкрементно.

Установка и настройка

Migraine настраивается с помощью ini-файла и путём редактирования скрипта (думаю, в будущем все изменяемые опции будут перенесены в файл настроек). В ini-файле нужно указать сервер, пользователя и пароль к двум базам данных — test и production. Можно не указывать пароли, тогда migraine будет каждый раз спрашивать их при запуске. Даём скрипту права на выполнение:

chmod +x migraine.py

Создаём в каталоге с migraine папку database и в ней ещё две: test_dump и prod_dump. У python должны быть права на чтение и запись в эти папки.

После этого запускаем сам скрипт (вначале на dev-сервере):

python migraine.py --config=migraine.ini

При запуске без параметров действия migraine сохраняет backup обеих баз, после чего его можно сохранить в репозиторий на всякий случай🙂 Если migraine встретит незнакомые таблицы, она выведет их список на экран. После этого надо открыть скрипт migraine.py и вписать таблицы в один из четырёх разделов:

  • config_tables: таблицы конфигурации. Они будут скопированы с dev на production
  • content_tables: таблицы с контентом. Будут скопированы с production на dev
  • temp_tables: временные таблицы. Они будут проигнорированы, но в будущих версиях могут очищаться
  • cache_tables: кеш-таблицы. Будут очищены
  • config_tables: таблицы конфигурации. Они будут скопированы с dev на production
  • sequence_tables: таблицы последовательностей. Они синхронизируются особым образом
  • ignored_tables: эти таблицы будут проигнорированы, никаких действий с ними производиться не будет

Использование

Чтобы перенести контент на тестовый сервер, надо запустить скрипт с ключом --migrate-to-test:

python migraine.py --dump-prod --config=migraine.ini
python migraine.py --migrate-to-test --config=migraine.ini

Обратите внимание, при каждом запуске надо явно указывать файл настроек. Чтобы перенести конфигурацию на production-сервер, надо запустить скрипт так:

python migraine.py --dump-test --config=migraine.ini
python migraine.py --migrate-to-prod --config=migraine.ini

Первая строка сохраняет дамп таблиц в каталог database/test_dump и database/prod_dump. Вторая обновляет базу данных из этих таблиц. Если production- и developement-сайты находятся на разных машинах, можно просто добавить эти каталоги в CVS вместе с кодом модулей.

В документации указано что с ключом --no-action migraine просто перечислит действия с базой, не выполняя их, но в последней версии этот ключ не распознаётся.

При синхронизации сайта использующего CCK может выдаваться сообщение о несовпадении схем базы. Это происходит от того что CCK перестраивает таблицы в соответствии с существующими в системе типами контента. Необходимо перенести настройки (а можно и контент) CCK с помощью встроенных средств самого модуля, и потом уже запускать migraine.

Рекомендованный алгоритм синхронизации

Сами авторы migraine рекомендуют следующий алгоритм синхронизации:

  • Зайдите на тестовый сайт по SSH
  • Убедитесь что изменения кода и возможные апгрейды модулей зафиксированы в VCS
  • Сохраните копию базы тест-сервера командой python migraine.py --dump-test
  • Внесите получившиеся файлы в систему контроля версий
  • Если production-сервер находится на другой машине, копируйте дамп базы туда (cvs/svn update должно быть достаточно)
  • В меню Admin / Site Maintenance на production переведите сайт в режим обслуживания (Maintenance)
  • Сохраните дамп базы production командой python migraine.py --dump-prod. Этот дамп будет бэкапом на случай если что то пойдёт не так.
  • Если PHP-скрипты изменялись, обновите их на production-сервере из репозитория
  • Запустите update.php на production-сервере, если модулям необходимо изменить что нибудь в схеме таблиц для контента (это могут быть например только что установленные модули).
  • Перенесите конфигурацию на production: python migraine.py --migrate-to-prod. Если миграция не срабатывает из за несовпадения схем CCK, повторите на production те же действия с типами контента, что и на test, и попробуйте ещё раз).
  • Очистите кеш CSS: rm /files/css/*
  • При желании можно опять сделать дамп базы production-сервера и закомиттить в систему контроля версий - как контрольную точку после успешной синхронизации
Добавить комментарий

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s