[mar]

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

[Prisoner]

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

[mar]

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 по-дефолту (что, впрочем, тоже не всегда однозначно стоит делать, так что статья, пожалуй, полезна).

[Vlad Drakula]

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

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

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

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

[mar]

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

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

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

[Imperio]

Vlad Drakula

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

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

[Vlad Drakula]

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

[Imperio]

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

[Ginger]

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

old-passwords
skip-networking
enable-named-pipe

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