Переносим БД MySQL с новой версии на старую

   В этой заметке я расскажу о своём опыте переноса базы данных MySQL версии 4.1.5 на сервер MySQL версии 4.0.24. Будет рассказано несколько способов переноса. Те, кто не понял первой фразы, дальше могут не читать - заметка предназначена для тех, кто работает с базами данных MySQL.    Итак, всё началось с очередного переезда проекта BlueJack.RU на новый хостинг. Со старого хостера я получил все бэкапы. Радостный, пока сайт ещё был на старом хостинге, я принялся за работу по переносу данных. Первая же попытка восстановить базу через shell нового хостера окончилась неудачей. Эта первая проблема, с которой я столкнулся, была в наличие разного рода лишней для более старой версии сервера MySQL информации. Пришлось вручную удалять строки типа "/*!Blah Blah Blah */", " ENGINE=MyISAM DEFAULT CHARSET=latin1" и некоторые другие, в которых упоминалась кодировка. Это не заняло много времени благодаря функции поиска/замены с использованием регулярных выражений в моём любимом редакторе Crimson Editor. Но, как оказалось, Crimson при всех своих достоинствах никак не принимал кодировку бэкапа, оставляя латиницу как есть, а кириллицу превращая во что-то невообразимое. Пришлось воспользоваться штирлицем. Я взял весь бэкап и разом скопировал его в Штирлиц (надо сказать, на моём измученном годами работы компьютере Штирлиц жевал около мегабайта текста с трудом).    Штирлиц вылечил кодировку, но оставил за собой сюрпризы вроде "левых" символов. При вставке в Штирлиц текста последний автоматически конвертируется в удобочитаемый. НО оставляет за собой пресловутые символы. (Например заменял сочетания знака равно и следующих за ним двух цифр каким-то другим одинарной кавычкой.) Это никуда не годилось, ведь лишняя неэкранированная кавычка приводит к известных последствия - невозможности восстановить бэкап, пока её не уберёшь. Вычитывать мегабайт текста, чтобы найти лишние кавычки, совсем не хотелось. В итоге решение получилось, мягко говоря, неординарное, и обнаружило себя совершенно случайно. Скопировав в очередной раз текст в Штирлиц, нажал отмену (не спрашивайте, зачем!). Вместо того, чтобы вернуть исходный текст, лишь программа исправила только некоторые символы (именно те, которые были помехой). Вот и верь после этого "умным" программам. После этого база данных сайта была успешно перенесена на новый хостинг.    На этом следовало бы сказать "Happy End" и поставить точку. Если не знать, что кроме сайта, есть ещё форум. База данных которого в несколько раз больше. В этом и заключалась новая проблема: мой компьютер в лице Штирлица не то что с друдом жевал такой файл - он его просто не мог засунуть в рот (читай: файл не открывался, программа висла). Тут-то я понервничал. Пришлось искать новое решение. Пришлось попросить у старого хостера ещё и исходные файлы базы данных (FRM, MYD и MYI). Ещё более древняя версия MySQL, установленная на моём компьютере (3.23.42), скушала тэти файлы и не поперхнулась. Я просто создал все таблицы, как в бэкапе форума, у себя в базе данных на своём компьютере, а затем заменил файлы созданных таблиц файлами бэкапа. Потребовалось заменить только MYD и MYI. (Не заменяйте FRM - будет ругаться и не будет работать.) И, к моему удовольствию, с кодировкой всё было нормально. Оставалось сделать бэкап локальной базы данных и перенести на сервер нового хостера. Здесь меня поджидала ещё одна неприятность. (На этот раз, последнняя.) Оказалось, что на хостинге было ограничение max_allowed_packet в 1 мегабайт. И если делать бэкап моего форума с опцией --extended-insert (с которой я его сначала и сделал после восстановления на своём компьютере), то это ограничение будет явно превышено. (Таблица сообщений форума в несколько раз превышает это ограничение). Оставалось заново сделать бэкап, но уже без --extended-insert. Комментарии временно отключены.

Скачать Переносим БД MySQL с новой версии на старую » высокоскоростная загрузка

MySQL версии с на Переносим старую новой БД » Pocket PC

Описание пакета
Переносим БД MySQL с новой версии на старую - описание для этого файла .