6 января 2010 в 20:18
Извините если не в ту ветку. Задача: проапгрэйдить друпал с 5 на 6.
132 Модуля на сайте.
15Gb static data.
11Gb БД.
Есть ли люди с опытом подобных операций? На что обращать внимание? Какие подводные камни?
Если кто может присоветовать "схему" апгрейда, буду очень благодарен.
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
www.spin.com
Только я собственно недавно начал работать 
Многое из того что там проинсталированно можно смело сносить, но дело сейчас не в этом. Вобщем-то многое уже сделанно по поводу миграции, просто хочется услышать стороннее мнение, ну и советы конечно.
Однозначно проблемы,если стоит i18n
Спасибо за комплимент, за совет, а i18n не стоит.
Категорически не использовать update.php с таким объемом данных пока не отключены все модули.
Смотреть на предмет хаков в установленных модулях, особенно на предмет структуры базы.
Конвертировать шаблоны темы.
1) начать с таблиц ядра, возможно придется прогонять куски update.php руками, потом остальные функции _update_N() из модулей ядра, причем из командной строки, потому как в браузере оно может не успеть отработать за отведенные ему N минут
2) по одному включать дополнительные модули, очень вероятно придется также руками обновляться
3) после каждого успешного шага бэкап
PS: не забыть рассказать о проделаной работе
Спасибо за совет! С удовольствием поделюсь опытом, после того как успешно это все проделаю
Может даже блог заведу, буду потихонку делится набитыми шишками.
Основное, хоть и очевидное:
И вам спасибо! Все делаю на локальном серваке в VmWare (от этого не легче, честно)
т.е. вы хотите сказать, что на винде, LAMP установленный в варю, будет жрать меньше чем WAMP развёрнутый на этой же винде?
Еще почистите кеш таблицы, акцесс-логи, вочдог. Объём БД станет существенно меньше.
Спасибо, вачдог почистил, а вот остальное упустил.
У меня в варе linux стоит, под эту машину выеделенно 2 гига памяти, мне хватает. А на счет LAMP, поясню что за неимением staging environment'a который бы максимально близко отражал конфигурацию сервера пришлось запользовать варю, так спокойнее (с прицелом на последующей перенос в production environment).
В таких случаях главный вопрос
ЗАЧЕМ
я имел ввиду - цели переход с 5 на 6.
132 модуля от Пятёрки можно сократить да 40-60 в Шестёрке. К тому же прогресс, это хорошо!-)
Проблемы с производительностью?
Не хватает функционала?
Хочу обратить внимание на тот факт, что для перевода больших проектов с 5 на 6 платформу требуется ОЧЕНЬ много времени и сил. Вспомните хотя бы с какими потугами сам drupal.org это делал.
Потому для этого нужны ОЧЕНЬ серьезные причины, чем просто уменьшение количества модулей, или эмпирические рассуждения о прогрессе.
P.S. Demimurych, без обид, но от вас, кроме регресса (табличная вёрстка, например) и пессимизма (в любом вашем посте), я, на д.ру, ничего не читал.
либо не представляет обьемов работ.
табличная верстка это мой любимый холивар, и даже с выходом ИЕ8 (при решения ряда задач) я любого любителя блочной ткну носом в дикое количество костылей которые им придется использовать. Но мы же не об этом?
Мы о том что на друпал ру, за редким исключением, вменяемых специалистов нет.
Ну а если лично обо мне и д.ру вот вам немного
http://www.drupal.ru/blog/15030
не говоря о том, что на drupal.ru вы пользуетесь, в том числе, и плодами моих трудов.
Причин много, вот хотябы тот факт что держать здоровый коммерческий сайт на платформе которую вот-вот перестанут поддерживать (в виду выхода Д7) не кошерно. Плюс производительность, плюст факт того, что до меня над саитом трудилось 3 группы умельецев, которые там налабали такого что папа с мамой плакали на взрыд. Переход позволит разобраться с кое-какими проблемами в этом коде. Дело еще в том что иначе как переходом не убедить начальство выделить время на refactoring старого кода. У них же все по принципу -- работает, значит нефиг трогать. Но на самом деле оно не очень работает. Например обьем трафика между БД и веб серверами почти в 10 раз больше чем входящего/исходящего. Нездорово когда для загрузки страницы требуыется > 250 кверей. Ну и т.д. не хотелось бы о грустном, но апгрейдить надо.
Основная ось Винда, а в варе линух, смысл в максимальном приближении среды разработки (с настроиками, фаиловой структурой, репликацией бд, и прочим) к живой среде. Ну и иногда я рисую
ну вот вменяемый ответ.
Возможно, очевидный совет - но его еще никто не посоветовал
Модуль Upgrade Status - http://drupalmodules.com/module/upgrade-status - покажет, для каких модулей есть новая версия, для каких нет + сразу можно скачать новую версию.
А совсем в ручную никто не пробовал?
Поделись впечатлениями, пожалуйста? Насколько проблематично? Были ли конфликты? Особенно с ССК. У меня сеичас такой план: потабличный перенос базы из 5-го в 6-ой, обновление контрибнутых модулей, обновление "домашних" модулей... тестирование... грубо говоря схема такая. Забил на родной update.php ибо он сцуко накрывается и накрывает за собой все вместе.