MySQL4.0->MySQL4.1 проблемы миграции - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Вебмастеру (http://forum.oszone.net/forumdisplay.php?f=22)

- - MySQL4.0->MySQL4.1 проблемы миграции (http://forum.oszone.net/showthread.php?t=44159)

Доброго времени суток, господа.
Кто-нибудь сталкивался в сети с доками по миграции mysql (win32) 4.0.x -> 4.1.x? Я имею ввиду как перенос данных, так и адаптацию клиентов (менеджеры, php).

Prisoner
может это в отдельную тему выкинем? вопрос в общем-то достаточно глобальный
у меня в прошлом году с переносом данных между версиями проблем не было. Были проблемы с PHP - кодом
вот тут - про проблемы с timestamp со ссылкой на www.opennet.ru.

Цитата:

From version 4.1, TIMESTAMP is returned as a string with the format
'YYYY-MM-DD HH:MM:SS' and different timestamp lengths are no longer supported.

ну, собственно, мы с тобой это уже обсуждали, это для "примкнувших к нам" :)
ну, а собственно, документации по изменениям - вагон и маленькая тележка :(
И даже статья Upgrading from Version 4.0 to 4.1 пошла читать :/
И на закуску Upgrading MySQL on Windows

mar
Глобальный, да, но кто им заморачивался? :) Пока двое (сорри, если кого, по причине отсутствия телепатических способностей, не учел).
Спасибо за ссылки, как я и говорил - в плане поиска по mysql.com у меня руки кривые :\

Prisoner
извини, мне попался новый материал по этому поводу и я все-таки решила выделить в отдельный топик. Если сочтешь неправильным - склеим обратно :)
Статья Перенос данных из MySQL 4.0 в 4.1.x через mysqldump от нового MySQL. Автор: Dmitry Molchanov

Цитата:

Итак, ситуация:
- новый db-сервер, с mysql 4.1.7
- необходимость проапгрейдить клиентскую библиотеку на тех серверах которые к нему будут обращаться.
- необходимость миграции данных с других mysql, которые 4.0
- базы все в cp1251

В качестве эксперимента апгрейдим mysql-client до 4.1.7 на первом db-сервере,
где стоит 4.0.20 и отпадание mysql-client'а на, пусть даже час, ни к чему фатальному не приведет...
На первый взгляд все гладко заапгрейдилось.

Вечером апгрейдим Mysql-client где надо, чего надо пересобираем... пока все гладко.

Начинаем миграцию данных, с того сервера где мы обновили Mysql-client в первую очередь.

Маленькая ремарка: mysql-(client|server) были собраны из портов с
WITH_LINUXTHREADS=yes
BUILD_STATIC=yes
BUILD_OPTIMIZED=yes
, т.е. с чарсетами по-умолчанию

- делаем дамп командой mysqldump --opt database > database.sql
- копируем дамп на новый сервер
- там в /etc/my.cnf уже прописано в [mysqld] default-character-set=cp1251.
- говорим create database db_name
- потом \. database.sql
- дамп разворачивается, но... с матами на дублирование ключа и с вопросиками в место русских буковок.
- пробуем set names cp1251 и снова развернуть дамп - та же история.

Потом пол-дня пробуем всякие разные комбинации с пересборкой mysql-server и всякими
настройками charset/collation, в результате удосуживаемся присмотреться к дампу
и увидеть там 'SET NAMES utf8' в самом начале. После замены оного на 'set names cp1251',
все встало на свои места.

Этот "set names utf8" появился когда новый mysqldump из mysql-client-4.1.7 взялся дампить
базу с cp1251 и, не получив информацию о collation/charset выставил то, что считал разумным - utf8.

Лечится созданием дампа с --skip-set-charset.

Примечание (кстати, озвученное в обсуждении статьи : можно не "лечить", а предварительно озаботится созданием клиентской базы с charset по-дефолту (что, впрочем, тоже не всегда однозначно стоит делать, так что статья, пожалуй, полезна).

я лично делал переходый между версия просто накатывая версиии одну надругую...

1) останавливаю серви
2) инсталирую новую версию
3) запускаю сервис

причем я этото делал как с 4,0 на 4,1 так и с 4,1 на 4,0

причем это можно делать обсолютно безболезнено, т.к. формат таблиц у них один и тотже!

недавно попалось еще несколько заметок, связанные именно с возможными проблемами перехода:

Цитата:

(4.1)... использует несколько другой протокол авторизации, несовместимый с PHP 4.3.10. Служебные таблицы, хранящие пароли пользователей, изменили свой формат. Кроме того, кодировка с именем win1251, ... в новой версии устранена, вместо нее — cp1251.

(из заметок про Денвер)

Vlad Drakula

Цитата:

причем я этото делал как с 4,0 на 4,1 так и с 4,1 на 4,0

А все зависит от того какие данные хранятся в Вашей таблице(ах) ну немного от рук :)
Знакомый проапдейтил сиквел так, что все данные сохранились нормально, но пароли клиентов не подходили.
Но вообще проблема с паролями может вылезти после, при попытке смены пароля юзером, но тоже можно вылечить увеличив длинну поля с паролем. Ну и когда собираешь, желательно указать --with-default-charset, так можно избежать многих проблем :)

Imperio
проблеммы могут с паролями возникнуть из-за смены алгоритмов авторизации, а не непосредственнно из-за не правильной миграции данных!

Может быть.....будем эксперементировать дальше.

ну и как эту проблему обойти?
на винде.
в ини стоит
[mysqld]

old-passwords
skip-networking
enable-named-pipe

пробовала и сервис стартовать с параметрами --old-passwords - не помогает. (точней вобще не стартуется...)

Ginger, для пользователей, которые будут получать доступ через php нужно шифровать пароль в таблице mysql.user функцией old_password(), а не password().

Если не ошибаюсь, в 4.1 изменена схема авторизации.
У меня была трабла только с кодировками и авторизацией. (на MySQL 5 перенос аналогичен)
Первое решил доп. командой в каждом php файле (понадобилось почему-то только в одном проекте) - mysql_query("SET NAMES cp1251"); Вставлять после mysql_select_db !
В остальных проектах просто назначил кодировку cp1251 в каждой таблице.
Второе решается заменой mysql.dll
P.S. Заставить работать связку PHP 4.4.1 + MySQL 5.0.1 мне не удалось. Ставьте PHP 5.x
Пользователей забить заново. old_passwords - откровенно костыль. Лучше перезабить их заново, обновив клиентов. Прямее, надежнее и безопаснее.

В связи с тем, что тема потеряла актуальность (ветка 4 больше не поддерживается) тема открепляется.