Итак, ситуация:
- новый 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.
|