|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Здравствуйте.
Попытаюсь подробно описать проблему.
Есть старый сервер с RH3 и mysql v 3.23, на сервере есть несколько баз данных, в некоторых из них есть довольно большие таблицы (25Гб). Особенность работы данного сервера заключается в том, что локаль сервака koi8r и база данных работает в этой же кодировке. Но сам mysql collate не поддерживает, он старый. Смотрю через phpmyadmin версии 2.3. Более свежие не ставятся, требуют более нового php.
Теперь имеем новый сервер с RH5 и mysql 5.0.77. Локаль этого сервера работает в utf8. Теперь задача переехать с одного сервера на другой и чтобы без проблем:
1. Не потерялись данные.
2. Работали старые php скрипты без допиливания.
3. Работали утилиты, запускаемые из консоли самого сервера без допиливания.
Переезд будет просто копированием файлов БД с одного сервера на другой. Полагаю, что при этом крайне желательно остановить mysqld на обоих сервера, а после копирования стартануть снова. Также на новом сервере нужно указать
default-character-set=koi8r
Будет ли этого достаточно и правильно ли осущесвляется переезд?
Очень надеюсь на разъяснения данного вопроса, потому что голова уже пухнет.
з.ы.
На серверах раз в месяц запускается отчетность. В прошлый месяц я парился много, кучу чего переделал, пришлось в php указывать в запросах SET NAMES koi8r. Вроде все заработало и посчиталось. Но начал делать в этом месяце и начали вылезать косяки. Например, перестали работать некоторые консольные скрипты, начали ругаться на то, что нельзя в условиях сравнивать поля с разными collation. Я уже столько всего делал и по-уму и наобум, что запутался окончательно.
Неактивен
Неактивен
Спасибо большое. Насчет правильного переезда вроде понятно. Попытаюсь придумать, какой метод лучше будет в моем случае. Вообще первый способ самый простой и легкореализуемый, но вот на новом сервере уже часть данных занесена после кривого переезда и если с бэкапа брать данные, то новые данные потеряются. Остаются другие 2.
Вот к примеру что быстрее обработает таблицу в 5Гб: конвертация в бинарный тип, а потом в koi8r или бэкап в дамп, редактирование/преобразование, загрузка данных из дампа? Сервер у меня не мегамощный и используется для работы. Занимать его надолго нельзя.
Неактивен
Но если вкратце — то да, для чтения данных этого должно быть достаточно.
Но надо понимать, что если клиент прийдет и скажет SET NAMES utf8 (99.9%
современных клиентов), MySQL начнет преобразовывать данные туда-обратно,
и ошибки с mixed collation очень даже возможны (попробуйте, например,
представить символ ́а в koi8 
).
Неактивен
Ух, пока писал — Вы меня обогнали 
Подозреваю, что они будут работать со сравнимой скоростью. Наверное,
работа через дамп будет с Вашей точки зрения быстрее, т.к. во время
дампа табличка остается доступной на чтение, а во время ALTER — она
заблокирована. Но запись надо будет блокировать в любом случае, иначе
данные потеряете.
Неактивен
paulus написал:
MySQL начнет преобразовывать данные туда-обратно,
и ошибки с mixed collation очень даже возможны (попробуйте, например,
представить символ ́а в koi8
Ну это очень врядли, что он придет Хотя тут как посмотреть. Есть php страница, в ней в заголовке явно указана кодировка koi8r. Т.о., как я понимаю, если пользователь введет данные, которые потом занесутся в таблицу, то они будут в кодировке koi8r? Или не обязательно и в php скрипте нужно обязательно "допиливать" SET NAMES koi8r? Файлов много, в которых допиливать придется.
paulus написал:
Но запись надо будет блокировать в любом случае, иначе
данные потеряете.
А можно ли в mysql именно запись как-то блокировать?
Еще загвоздка в том, что в начале месяца одну из таблиц обновляли с 3го сервера путем простого копирования, теперь же придется каждый раз делать дамп базы, конвертить его, очищать таблицу-преемник и загружать в нее данные дампа Это печально.
Неактивен
А еще я думаю стоит ли все поля переводить в koi8r или только выборочно те поля, в которых могут быть русские символы? Дело в том, что в самых больших таблицах данные хранятся в латинице, если там и есть ошибочные данные на русском, то их 0.01%, которым можно пренебречь.
Неактивен
MySQL в качестве кодировки по умолчанию берет свой default-character-set.
Но у клиента умолчание может быть другое. Передает ли PHP кодировку — не
знаю. Скорее всего, нет.
Блокировать табличку проще всего так: LOCK TABLES tablename READ. При
этом, пока соединение живо, будет держаться блокировка над этой табличкой.
Ничего конвертить не надо. Если у сервера стоит правильная кодировка по
умолчанию, то для всех старыъ (т.е. те, в которых кодировка не прописана)
файлов он будет считать, что кодировка совпадает с его кодировкой по умолчанию.
Хотя, на третьем сервере тоже неплохо бы обновить ПО
Неактивен
А еще у Вас есть странная тенденция писать, пока я отвечаю
Преобразовывать ли одно поле или несколько — не имеет значения. Все
равно это будет запрос, который перелопачивает все данные.
Неактивен
paulus написал:
Ничего конвертить не надо. Если у сервера стоит правильная кодировка по
умолчанию, то для всех старыъ (т.е. те, в которых кодировка не прописана)
файлов он будет считать, что кодировка совпадает с его кодировкой по умолчанию.
Хотя, на третьем сервере тоже неплохо бы обновить ПО
Хм, т.е. если я Вас правильно понимаю, то мне достаточно в my.cf установить дефолтную кодировку koi8r, остановить mysqld, переписать интересующие меня таблицы на сервер, запустить mysqld и он будет считать, что поля таблиц в koi8r?
Обновить то да, но нет. RedHat в этом плане консерватор. Свои srmp он выпускает только до определенных версий, выше которых их тупо нет. К примеру тот же mysql нативно именно RedHatовским апдейтом не апгрейднешь, а если делать вручную, то там столько зависимостей пакетов, что можно рехнуться. Оба этих сервера, 1й источник для 2го нового и 3й, с которого берется 1 табличка очень старые, работают для авторизаций и следуя главному правилу админа "работает? не трогай" трудятся себе потихоньку. Но вот 1й сервак-источник получилось обновить на чуть более производительное железо, потому и ОС поставили более новую.
paulus написал:
А еще у Вас есть странная тенденция писать, пока я отвечаю wink
Преобразовывать ли одно поле или несколько — не имеет значения. Все
равно это будет запрос, который перелопачивает все данные.
Да нет вроде
Ну за 1 раз преобразуется 1 поле таблицы. Причем это поле надо преобразовать 2 раза: 1й раз в бинарную версию, а потом уже в нужную кодировку. Причем массово запрос на изменение не сделаешь, так как длина поля у всех полей разная
Неактивен
Честно говоря, не понял, что Вас смущает.
ALTER TABLE tablename MODIFY a BINARY(100), MODIFY b VARBINARY(19);
Неактивен
А, ну да Что-то затормозил. Спасибо, многое стало понятно. Вот что значит не администратор БД, а так, "поковыряться".
Неактивен
Оказалось, что некоторые поля в таблице коллега перевел в utf8 и данные в utf8 перезанес. Но теперь такая ситуация. Когда базу в php коннекчу, то сразу задаю SET NAMES koi8r. И теперь при обращении к таблицам с utf8 выводятся кракозябры. Если делать SET NAMES utf8, то при запросах к таблицам с данными в koi8r тоже выводятся кракозябры . Можно ли utf8 перевести в koi8r без потери данных простым изменением collation'а?
Неактивен
utf8 в koi8r без потерь перевести нельзя, так как всегда есть шанс, что встретится
символ, который не представим в последней кодировке.
А коллега, который перезанес, — он их в правильной кодировке перезанес?
Неактивен
Да, он сделал collation utf8 и данные там в utf8. Ну ладно, там в принципе таблички не большие, можно вручную данные перенести через sql-запросы, а не конвертацию.
Неактивен
Страниц: 1
