Перенос базы Mediawiki – решение проблемы с кодировками
Так сложилось, что я уже несколько лет веду все личные и рабочие заметки в локально установленной Mediawiki. Как показал мой опыт это весьма удобно – можно набросать по-быстрому статью, в которую затем добавить дополнительную информацию (например графику), дополнить ссылками как внутренними так и внешними. И поиск есть. Получается такая википедия для внутреннего пользования, ценность которой с годами все возрастает и возрастает.
На днях я решил перенести мою Wiki на другой сервер, и столкнулся с неожиданными проблемами, которые растянули этот процесс на 3 дня.
Сначала застрял на том, что при попытке отображении статей мне выдавалась ошибка mysql:
MySQL returned error “1267: Illegal mix of collations (latin1_bin,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation ‘=’ (localhost)”.
Избавиться от ошибки получилось после того, как я задал в рабочей базе кодировку utf8 вместо latin1 для столбцов с типом VARCHAR (рецепт взят отсюда). При этом, пришлось модифицировать индекс “cl_to” в таблице “categorylinks” (уменьшить число символов, учавствующих в индексе), потому что иначе выдавалось сообщение об ошибке:
Specifiend key was too long; max key length is 1000 bytes
После обновления полей базы сделал дамп, загрузил его на сервер назначения, и столкнулся с другой засадой – русский текст в статьях показывается “кракозябами”, а статьи с русскими названиями вообще не находятся. Танцы с бубном не помогли:
- выгружал дамп с опцией –default-character-set=utf8;
- пытался сконвертировать дамп различными утилитами в utf8 (в итоге так и не нашел ни одной программы, которая корректно бы показала то что создается с помощью mysqldump);
В конце-концов, наткнулся на рецепт в блоге, который мне помог: создал дамп базы с помощью утилитки Sypex Dumper (написанной на PHP, кстати), и развернул его с её же помощью на сервере. Надо только явно задать значения констант CHARSET и RESTORE_CHARSET внутри скрипта перед его запуском:
define(’CHARSET’, ‘latin1′);
define(’RESTORE_CHARSET’, ‘utf8_general_ci’);
И это действительно работает! Mediawiki успешно перенесена на другой сервер, проблема с кодировками решена!
Да, саму Wiki я не переинсталлировал, просто скопировал директорию и поправил файл LocalSettings.php – поменял пути к базе и установил значение TRUE для переменной $wgDBmysql5.
Меня зовут Владимир. Я живу в России, в 
18 коммент. к “Перенос базы Mediawiki – решение проблемы с кодировками”
Дмитрий - Янв 6, 2009 | Ответить
Здравствуйте, Владимир
Спасибо за ссылку. Опыты с Медиавики действительно нечто незабываемое, думаю такие танцы с бубном – что-то вроде “расплаты” за широкие возможности движка. (Справедливости ради замечу, что несмотря на то, что администрирую один сайт на сабже, моя персональная вики работает на oddmuse.)
С праздниками!
mvs3d - Янв 7, 2009 | Ответить
Если говорить о кодировках, то тут скорее расплата не за широкие возможности движка, а за его возраст
Дело в том, что у меня есть собственный проект которому потребовалась ровно эта же операция чтобы получить читаемый UTF-8 текст в базе после ее миграции на MySQL 5.x
yurand - Апр 5, 2009 | Ответить
При создании бэкапа вики в dumper возникает ошибка:
2009.04.05 17:50:19
Возникла ошибка!
Undefined index: archive (8)
Причем ошибка возникает только при бэкапе базы вики. Подскажите, пожалуйста, в чем дело…
mvs3d - Апр 5, 2009 | Ответить
Ну, судя по тексту ошибки база не находит индекс “archive” который пытается забакапить. Странно это все. Попробуйте запустить ремонт таблиц. Только перед этим на всякий случай скопируйте файлы с данными куда-нибудь отдельно (сервер надо при этом остановить).
yurand - Апр 6, 2009 | Ответить
mvs3d, спасибо за ответ!
У меня есть несколько установленных вики, в том числе один на нормальном хостинге. Ошибка “Undefined index” для таблицы archive возникает при попытке создать дамп для всех этих вики.
При этом дамп спокойно создается для других баз (интернет-магазин). Не может ли это быть особенностью новой версии вики?
mvs3d - Апр 6, 2009 | Ответить
Упс.. речь то действительно идет о таблице “archive” а не о индексе с таким именем. Что-то дурь какая то
Там в этой таблице у меня 1 индекс только:
KEY `name_title_timestamp` (`ar_namespace`, `ar_title`, `ar_timestamp`)
что означает в вашем сообщении об ошибке цифра 8 в скобках мне не понятно.
А если попробовать создать таблицу тестовую, в нее данные перекинуть и только ее задампить, что будет?
create table archive_test like archive;
insert into archive_test select * from archive;
Починку для этой таблице пробовал пускать, так, на всякий случай чтоб не думалось
?
yurand - Апр 6, 2009 | Ответить
Я когда устанавливал вики то установил:
Database character set на MySQL 4.1/5.0 binary.
Так вот именно для таких таблиц дампер и выдает ошибку.
Не подскажете, что можно с этим поделать?
mvs3d - Апр 6, 2009 | Ответить
Честно говоря, не знаю
Утилитку Sypex Dumper которая упомянута в этом посте наверное пробовали?
yurand - Апр 6, 2009 | Ответить
Именно в ней ошибка и возникает.
yurand - Апр 6, 2009 | Ответить
Еще раз проинсталлировал вики. На этот раз с Database character set = UTF-8. Теперь дампер работает без ошибок.
Интересно, как заставить работать его с binary? :-/
mvs3d - Апр 6, 2009 | Ответить
Блин, вот я не въехал сразу что это вы дампером делаете, – думал mysqldump у вас такое пишет
Попробуйте написать в его коде (заменить define(’CHARSET’ который там был):
define(’CHARSET’, ‘binary′);
mvs3d - Апр 6, 2009 | Ответить
А нафига базу в binary создавать, кстати? Чем UTF-8 не устраивает?
yurand - Апр 6, 2009 | Ответить
Формат binary стоял по умолчанию (как рекомендуемый). Поэтому и не стал его менять. А define(’CHARSET’… к сожалению не помогает. Та же ошибка.
Sypex заявил о выходе нового дампера. Может он потянет.
majestic - Май 10, 2009 | Ответить
У меня также binary и также ошибка в дампере Undefined index: archive (8)
Кстати, бекап в phpmyadmin создаю, на локальном сервере пробую поднять из бекапа, пишет “нет запроса SQL”. Как-нибудь еще можно попробовать создать бекап? Есть варианты?
mvs3d - Май 10, 2009 | Ответить
Версии MySQL (удаленная и локальная) совпадают? Чем скрипт из бакапа поднимаете?
Денис - Май 10, 2009 | Ответить
бекапил с phpmysql 2.11.9.1 переносил в локал на phpmysql 2.6.1, видимо в этом дело
Проблему решил…Для тех у кого бд в бинари и дампер показывает ошибку archive (8) используйте mysqldumper 1.22. Без проблем снял бекап базы с сервера, попробовал восстановить на другую перварительно созданную базу на сервере, изменил настройки локалсетингс, работет. Также пробовал в локале, на денвере, все работает!
mvs3d - Май 10, 2009 | Ответить
Ясно. Спасибо что отписались!
Денис - Май 10, 2009 | Ответить
update:
phpmysql 2.11.9.1 -> phpmyadmin 2.11.9.1
phpmysql 2.6.1 -> phpmyadmin 2.6.1
версия mysql сервера
на сервере 4.1.22-log
в локале 5.0.45-community-nt