Mvs3d.ru: блог Web-разработчика

Решил обновить на локальной машине (Windows XP) версию MySQL с 4.1.11-nt до 5.0.51b-community-nt (самая свежая стабильная версия на настоящий момент).

Казалось бы, алгоритм прост: делаем бакап всех баз сразу (с помощью mysqldump с опцией “-A”), деинсталлируем текущий сервер, ставим новый и выполняем restore через консольку mysql, используюя полученный ранее скрипт.

На всякий случай (и как оказалось впоследствии совсем не зря!) я сделал копию “сырых” таблиц – заархивировал директорию описанную опцией “datadir” в конфигурационном файле my.ini К сожалению, я забыл забакапить таблицы, хранящиеся в InnoDB (путь задан в конфиге “innodb_data_home_dir”).

После установки 5-ки совершенно неожиданно столкнулся с проблемой. SQL скрипт выполнялся с ошибкой:

ERROR 1064 (42000) at line 23117: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘BTREE (`location_id`,`location_name`),
SPATIAL KEY `location_point` (`location’ at line 8

Полный SQL-оператор, приведший к ошибке выглядит так:

CREATE TABLE `company_locations` (
`location_id` int(15) NOT NULL auto_increment,
`company_id` int(15) default NULL,
`location_name` varchar(100) NOT NULL default ”,
`location_point` point NOT NULL default ”,
`location_polygon` polygon NOT NULL default ”,
`min_zoom_level` int(10) unsigned NOT NULL default ‘12′,
PRIMARY KEY TYPE BTREE (`location_id`,`location_name`),
SPATIAL KEY `location_point` (`location_point`(32)),
SPATIAL KEY `location_polygon` (`location_polygon`(32))
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Оказывается в 5-ке изменился синтаксис оператора создания таблицы, и вместо “KEY TYPE BTREE” надо писать “KEY USING BTREE”.

Хорошо, заменил все такие операторы по тексту (что было не легко, т.к. файл имеет размер около 100Мб и многие текстовые редакторы впадают в ступор при таком объеме). Решение нашел относительно быстро поставив бесплатный шестнадцатеричный редактор XVI32.

Теперь скрипт выполнился без проблем.. Попробовал подключаться к разным базам, – все как будто нормально. Доступ из PHP не работал, выдавая ошибку: Warning: mysql_connect() [function.mysql-connect.html]: Client does not support authentication protocol requested by server; consider upgrading MySQL client in…

Ну с этим нашел как бороться (знакомая штука с версии 4.1), решение описано тут. Вратце, заходим в консоль mysql и для каждого юзера выполняем команду:

SET PASSWORD FOR ’some_user’@’some_host’ = OLD_PASSWORD(’newpwd’);

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

Коллега (наш администратор), посоветовал сконвертить скрипт в UTF-8, мол 5-ка работает с этой кодировкой. Дал и пример команды (взятый отсюда):

iconv -f ISO-8859-15 -t UTF-8 file1.sql > file2.sql

Правда iconv у меня не установлен, поиски версии для Windows ничего не дали. Стал искать аналогичные конвертилки. Оказалось это не так то просто.. но в итоге нашел бесплатную конвертилку – “Simple Text Encoding Converter“. Правда в заявленном списке поддерживаемых кодировок не было ISO-8859-15, но из Wikipedia я узнал что иначе она называется latin9, а она поддерживается программой. Запустил конвертацию скрипта из latin9 в utf8. С моему удивлению, конвертация 100 мегабайтного файла отработала быстро… но скрипт не выполнился, вылетал с ошибкой:

ERROR 2006 (HY000) at line 654: MySQL server has gone away.

Пришлось задуматься. Ничего не получается, – пробую читать инструкции здесь и здесь

Ничего похожего на мою ситуацию я там не увидел, зато увидел упоминание об утилите mysql_upgrade, которую обнаужил в папке bin. Далее я взял сырые данные, сохраненные из старой версии MySql и попробовал запустить эту утилиту. На первый взгляд она отработала нормально, но полазив по своему Wiki я с удивлением обнаружил, что там пропали некоторые статьи. Это что-то! Задумался, почему так может быть.. и вспомнил про данные в InnoDB. Как я уже говорил ранее, их я забыл забакапить прямо перед апдейтом сервера, поэтому пришлось довольствоваться данными недельной давности (слава Богу, недавно винт менял и они там остались!).

С файлом для InnoDB я получил практически полную версию моих данных (все-таки некоторые статьи, которые я сделал на этой недели были утрачены). Но это все-таки лучше, чем совсем ничего.

Итак, если вы решили обновить MySQL с версии 4.x до 5.x мои советы:
- зайдите на mysql.com, изучите информацию по апдейту;
- выполните REPAIR для всех баз;
- сделайте полный бакап данных (не только SQL скрипт, но и сырых таблиц, не забывая при этом про InnoDB);
- деинсталлируем MySQL 4.x;
- инсталлируем MySQL 5.x;
- выполняем команду: mysql_upgrade -u root -p > result.txt;
- смотрим result.txt, проверяем таблицы;

Если что-то не так, – пробуем вытащить данные их скриптов. Особое внимание уделяем данным, хранящимся в UTF-8. Кроме этого, рекомендую важные для вас базы данных сохранить в отдельных скриптах (из старой версии mysql, перед деинсталляцией).