Натягивание Drupal на PostgreSQL

Зачем мне это?

Причин две:

• С PostgreSQL я работаю уже лет 10 (тогда же я первый раз отказался от MySQL, не устроила производительность на первой версии черного квадрата), все знаю, умею и все такое. Этой причины, собственно, достаточно.
• MyISAM неделю назад имел честь развалиться на пустом месте (без ресета сервера, перезапусков MySQL и вообще под нулевой нагрузкой), говорят что это обычное его поведение. Производительность InnoDB (даже с большим кэшом, больше всех данных) меня не устроила (причем, Петр Зайцев на HL++, улыбаясь, заметил, что это для InnoDB нормально, без тщательной настройки нормально не работает, что и дает MySQL-консультантам кусок хлеба).

Совместимость Drupal и PostgreSQL

Drupal Core

Весной 6-й Drupal был в виде версии 6.2, совместимость которой с PostgreSQL была условной: даже core modules работали не все (даже редактирование блоков не работало). К версии 6.5 все известные мне баги поправили, всеми входящими в поставку модулями вроде бы можно пользоваться, я проверил.

Единственная особенность, побороть которую быстро нельзя (и в реальной жизни - можно наплевать, если все тщательно тестировать и править по месту): PostgreSQL ругается, если вы пытаетесь вставить в varchar(n) строку длиннее n, а MySQL эту строку тихо обрезает по месту. Postgres ведет себя по стандарту, MySQL - по-лемминговски, можно многого в этом месте наговорить, ну да ладно.
К сожалению, проблема проявляется псевдослучайно: то какой-то модуль обзывает себя длинее чем 16 символов при записи в лог, то строчка локализации окажется длиннее 255 символов.
Единственный способ борьбы - читать логи и дотачивать напильником те места, где вставляемая строка слишком длинная.

Помимо этого, используемый эскейпинг спецсимволов приводит к warnings в логе. Это лечится вот этим патчем.

Если ваша установка Postgres имеет настроенную default-клиентскую кодировку, отличную от UTF8, то нужен еще вот такой патч, который явно выставляет кодировку после коннекта к базе данных.

Дополнительные модули

Потребовались правки

Единственный модуль, потребовавший серьезных правок - это Comment Subscribe. Он написан на хардкорном MySQL, с использованием ifnull, if, concat и update table1,table2, что ни в какие стандартно-SQL-ные ворота никак не лезет. Пришлось его изрядно дописать, патч к версии 6.x-1.1 можно взять тут: comment_subscribe-pgsql.diff или в моем багрепорте. Помимо нестандартных SQL-запросов, мой патч правит еще и ошибку, возникающую при установке модуля на сайт, где никаких комментариев еще нет.

Работают из коробки

Протестированы и работают без правок:

1. Admin Block
2. GeSHi Filter и GeSHi node
3. Image, Image assist, Image Attach, ImageMagick Advanced Options
4. Advanced Help
5. Site Menu
6. Taxonomy Menu
7. CAPTCHA pack, Random CAPTCHA
8. Tagadelic
9. Views

Перенос живого сайта с MySQL на PostgreSQL

Формально все очень просто: нужно перенести структуры данных, сами данные, переключить data source в конфигурации и настанет восторг и благолепие.

В реальной жизни все сложнее: прямой перенос структуры таблиц не работает (в деталях не разбирался). Кроме того, c Postgres не работает модуль Backup and Migrate, а быстрый взгляд в его нутро показал, что дешево запустить его не получится.

Альтернативное решение: создать нужную структуру данных самим Drupal-ом, а для переноса данных написать маленький скрипт.

В Drupal свои структуры данных в БД может иметь любой из модулей, поэтому работающая процедура переноса выглядит так:

1. Разворачиваем Drupal, накладываем необходимые патчи (см. выше), ставим нужные модули, накладываем патчи и на них (если нужно). Собственно, если Drupal уже установлен, то можно попатчить имеющуюся инсталляцию, в этом случае переносимый сайт должен иметь свой каталог в sites/ (не быть default).
2. Запускаем на этой установке новый Drupal-сайт, использующий Postgres, с произвольным именем сайта (на этапе копирования данных все данные будут заменены на данные с исходного сайта).
3. Разрешаем все модули, установленные на сайте-источнике. Это создает необходимую структуру таблиц и секвенсоров. Если какой-то из модулей был установлен на исходном сайте ранее, а сейчас отключен, то на новом сайте его нужно включить (и можно сразу выключить - все таблицы уже созданы).
4. Запускаем мегаскрипт копирования данных (подробнее ниже)
5. Если используется перевод интерфейса, то экспортируем данные старого сайта и импортируем на новый (данные locale мегаскриптом не копируются т:к: там бывают битые данные, у меня они были).
6. Копируем содержимое каталога files из старого сайта в новый c сохранением прав на файлы.

Замечание. Если у вас нет shell-доступа к серверу, на котором все установлено, то я не знаю чем вам помочь. Все мои рецепты предполагают полный доступ к серверу.

Мегаскрипт drupal-mysql2pgsql.pl

Сам скрипт можно скачать здесь: drupal-mysql2pgsql.pl.gz (не забудте распаковать перед запуском).

Для работы скрипта требуется Perl 5.x (у меня везде 5.8) с библиотеками DBI, DBD:Pg и DBD::mysql.

Параметры запуска: drupal-mysql2pgsql.pl source-db dest-db, где source-db - имя базы данных MySQL, dest-db - имя базы данных PostgreSQL.

Предполагается, что к обоим базам данных вы имеете доступ без пароля, если это не так, то проще поправить скрипт по месту (добавить username/пароль в вызовы DBI->connect).

Скрипт делает:

• Получает списки таблиц в исходной базе и в БД назначения, ругается (и продолжает работать) если в БД назначения чего-то не хватает.
• Стирает все данные из таблиц БД-получателя.
• Копирует данные из исходной базы в БД-получателя. Не копируются таблицы cache* и locales*, первые не нужны, а вторые копируются штатными средствами (копирование locales отключено т.к. я столкнулся с тем, что Drupal помещает туда данные в неизвестной науке кодировке, что обижает PostgreSQL).
• Инициализирует все секвенсоры в правильное значение (max(нужный_столбец).

Скрипт предоставляется AS IS, хочется надеяться, что те, кому он действительно нужен - сумеют разобраться в 120 строчках перла.