Перейти к контенту
  • 0

Перевод базы с 2.1.7 на 3


Endy

Вопрос

Рекомендуемые сообщения

  • 0
Планирую купить v.3.3 У меня рабочая версия 2.1.7. Подскажите, будут ли проблемы с перенесением базы данных?

Если делаить всё по инструкции, то не будет. Только про бекапы не забавайте, никто не знает что у вас с 2.1.7 могло быть. Советую сначал сделать апгрейд до 2.3,.x а потом уже до 3.x.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Спасибо за ссылку, очень пригодится! Я думаю, что не буду апгрейдить существующий форум. Поставлю на отдельный поддомен новый движок, и потихоньку буду пробовать переносить базу. Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Начал эпопею с переводом базы. Вот прям чувствовал, что будут проблемы. Никогда ничего так просто не даётся :D

 

Делал всё по-инструкции, благо SSH доступ к серверу у меня есть, это многое упростило.

 

1. Переконвертировал сохранённую базу данных с помощью iconv из latin1 в utf8

2. Заменил в базе SET NAMES и DEFAULT CHARSET на utf8

3. Импортировал этот дамп в созданную для этой цели БД и указал в conf_global.php, чтобы установленная начисто тройка эту базу использовала.

4. Захожу на форум и....

 

Вот что получил за свои труды:

 

Fatal error: Uncaught exception 'Exception' with message 'Не удалось инициализировать регистр, кеш настроек либо пуст, либо испорчен' in ipsRegistry.php:1695 Stack trace: #0 ipsRegistry.php(498): ipsRegistry->setUpSettings() #1 /admin/sources/base/ipsController.php(75): ipsRegistry::init() #2 /admin/sources/base/ipsController.php(62): ipsController->init() #3 /index.php(24): ipsController::run() #4 {main} thrown in /admin/sources/base/ipsRegistry.php  on line 1695

 

Подскажите, как это понимать? ;)

Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0
3. Импортировал этот дамп в созданную для этой цели БД и указал в conf_global.php, чтобы установленная начисто тройка эту базу использовала.

То есть вы базу с 2.1.7 присоединили к IPB 3? ;)

 

Подскажите, как это понимать?

А если попробовать -- http://mydomain.ru/forum/admin/upgrade/ :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0
То есть вы базу с 2.1.7 присоединили к IPB 3? :)

 

Это была плохая идея? Почему?

Подскажите, как это понимать?

А если попробовать -- http://mydomain.ru/forum/admin/upgrade/ :D

 

Вот спасибо! Теперь всё получилось. Но все буквы в виде наипрекраснейших кразозябр. ;) По-моему я где-то встречал решение, да вот где не помню...

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Это была плохая идея? Почему?

Формат базы другой

 

Вот спасибо! Теперь всё получилось. Но все буквы в виде наипрекраснейших кразозябр. :D По-моему я где-то встречал решение, да вот где не помню...

http://wiki.iblink.ru/ipb3/upgrade

 

И по форуму не раз и не два обсуждали

Изменено пользователем P(A)
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Формат базы другой

 

На что это влияет или повлияет?

 

 

http://wiki.iblink.ru/ipb3/upgrade

И по форуму не раз и не два обсуждали

 

Странно, но добавление .htaccess c не помогло. :D

AddDefaultCharset utf-8
AddCharset utf-8 *
<IfModule mod_charset.c>
CharsetSourceEnc utf-8
CharsetDefault utf-8
</IfModule>

Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Странно, но добавление .htaccess c не помогло. :D

IPB 3.0 русский или английский?

 

Точно база в utf-8?

 

1. Переконвертировал сохранённую базу данных с помощью iconv из latin1 в utf8

2. Заменил в базе SET NAMES и DEFAULT CHARSET на utf8

3. Импортировал этот дамп в созданную для этой цели БД и указал в conf_global.php, чтобы установленная начисто тройка эту базу использовала.

Лучше заменять скриптом от Ritsuka -- http://forums.ibresource.ru/index.php?showtopic=58417

Изменено пользователем P(A)
Ссылка на комментарий
Поделиться на других сайтах

  • 0
IPB 3.0 русский или английский?

Точно база в utf-8?

IPB 3.0.5 русский, скачанный в клиент-центре.

Точно. В phpmyadmin некоторые таблицы в utf8_general_ci, а некоторые в utf8_unicode_ci

До конвертирования были в latin1_swedish_ci

 

 

1. Переконвертировал сохранённую базу данных с помощью iconv из latin1 в utf8

2. Заменил в базе SET NAMES и DEFAULT CHARSET на utf8

3. Импортировал этот дамп в созданную для этой цели БД и указал в conf_global.php, чтобы установленная начисто тройка эту базу использовала.

Лучше заменять скриптом от Ritsuka -- http://forums.ibresource.ru/index.php?showtopic=58417

 

Только что попробовал этот скрипт. Сконвертировалось без ошибок. Затем запустил upgrade. В итоге те же самые кракозаблы. :D

В админке форума проверил - UTF-8

В настройке языков стоит ru_RU.utf8

На сервере локаль ru_RU.utf8 присутствует.

 

Кстати, когда просматриваю содержимое таблиц через phpmyadmin, вижу те же кракозяблы вместо русских букв.

 

Ничего не понимаю...

Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0
IPB 3.0.5 русский, скачанный в клиент-центре.

С ним проблем быть не должно.

 

А что за хостинг?

 

Кстати, когда просматриваю содержимое таблиц через phpmyadmin, вижу те же кракозяблы вместо русских букв.

Это зависит как сам phpMyAdmin подключается к базе.

 

Если сделать запрос

SHOW VARIABLES LIKE 'character_set%'

 

Какой ответ?

 

Ничего не понимаю...

Если менять в браузере кодировку страниц, можно добиться нормальных букв?

 

Все бьется или часть русских слов есть? А админка как?

Ссылка на комментарий
Поделиться на других сайтах

  • 0
А что за хостинг?

 

Хостинг в Эстонии. Вряд ли название вам известно..

 

Если сделать запрос

SHOW VARIABLES LIKE 'character_set%'

Какой ответ?

 

character_set_client 	utf8
character_set_connection 	utf8
character_set_database 	utf8
character_set_filesystem 	binary
character_set_results 	utf8
character_set_server 	latin1
character_set_system 	utf8
character_sets_dir 	/usr/local/mysql-5.1.39-linux-i686-glibc23/share/charsets/

 

 

Похоже проблема в этом: character_set_server latin1

Возможно ли как-то ее сменить или это зависит от хостера?

 

Если менять в браузере кодировку страниц, можно добиться нормальных букв?

 

Перепробовал все мыслимые кодировки, нормальных букв не добиться.

 

Все бьется или часть русских слов есть? А админка как?

 

С админкой порядок. Всё, что касается букв, установленных новой IPB3 - они отображаются нормально. Бьются только данные со старой базы.

 

Ради эксперимента поставил IPB 2.3.6. База импортировалась без проблем и всё прекрасно заработало. Причём, как в оригинальной кодировке latin1, так и после конвртирования в utf-8. Затем взял уже из 2.3.6 базу и проапгрейдил до 3.0.5 - проблема вернулась.

 

P.S. Очень благодарен за участие! Здорово, что есть такие люди.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Хостинг в Эстонии. Вряд ли название вам известно..

Понятно

 

Похоже проблема в этом: character_set_server latin1

Не в этом. Это не страшно.

 

Возможно ли как-то ее сменить или это зависит от хостера?

Сменить можно только если личная база данных. VDS, Сервер

 

С админкой порядок. Всё, что касается букв, установленных новой IPB3 - они отображаются нормально. Бьются только данные со старой базы.

Проблема в конвертации. Надо подумать.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Только сегодня столкнулся с таким форумом. Ну ни в какую не хотел конвертироваться как надо - весь в вопросиках был :D

 

Экспортировал базу в файл, прогнал через iconv и замену строк. Затем очистил БД, перевел её в utf-8 и только потом импортировал дамп назад. По такой схеме конвертировалось без "вопросиков".

 

Проблема была в том, это mysql козявил базу еще до конвертирования её скриптом, в процессе создания копии, а конвертировать сразу оригинал как-то не хотелось ;)

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Ritsuka, спасибо за ответ. Я правильно понял?

 

1. С помощью SypexDumper (например) делаю дамп старой базы

2. Конвертирую этот дамп в UTF8 и заменяю строки

 

iconv -f latin1 -t utf8 dump.sql > dump.utf8

sed 's/SET NAMES latin1/SET NAMES utf8/g' < dump.utf8 > 1.dump.utf8
sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/g' < 1.dump.utf8 > dump.utf8.sql

 

3. Очищаю старую базу (т.е. базу существующего форума), удалив из нее все таблицы или только данные? (в phpmyadmin)

4. Перевожу старую базу в UTF8

ALTER DATABASE real_db DEFAULT CHARACTER SET utf8 COLLATEutf8_general_ci

5. Импортирую дамп обратно

mysql -u real_db  -p np12524_second < dump.utf8.sql

 

Неужели другого выхода нет, кроме как заниматься с работающей базой? Я ещё не готов перевести форум на новую версию, там будет много работы с модифицированием, написанием хелпа по новому функционалу итд. Поэтому хотел сначала поставить новую версию на отдельный поддомен и данные старого форума скопировать в отдельную базу.

Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Только сегодня столкнулся с таким форумом. Ну ни в какую не хотел конвертироваться как надо - весь в вопросиках был :D

Мне такого еще не попадалось. Но ждал...

 

1. С помощью SypexDumper (например) делаю дамп старой базы

2. Конвертирую этот дамп в UTF8 и заменяю строки

Насколько я понимаю, да. Вашей ситуации, только через iconv

 

3. Очищаю старую базу (т.е. базу существующего форума), удалив из нее все таблицы или только данные? (в phpmyadmin)

4. Перевожу старую базу в UTF8

Не обязательно. Вам не кто не мешает импортировать дамп в новую базу, созданную в UTF8. Старый форум, будет работающий.

 

 

 

P.S. Что интересно, я тестовый форум ставил еще до выхода русской версии IP.Board 3. Ставил английскую. Тогда про базу данных в UTF8 я не знал. На английской версии, хостинг в Англии, база данных естественно в Latin1. Русский язык, работал корректно.

P.P.S. На русской версии скрипта, такое не пройдет.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Только сегодня столкнулся с таким форумом. Ну ни в какую не хотел конвертироваться как надо - весь в вопросиках был :D

Экспортировал базу в файл, прогнал через iconv и замену строк. Затем очистил БД, перевел её в utf-8 и только потом импортировал дамп назад. По такой схеме конвертировалось без "вопросиков".

 

Попробовал такой вариант, увы тоже не помогает.

Пробовал в index.php дописывать

header ("Content-Type: text/html; charset=utf-8");

Но, также ничего не поменялось.

Написал в сл. поддержки, может быть там что-то посоветуют.

Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Ну это у меня тестовый форум, там можно было издеваться :D А вообще, конечно, лучше новую сразу в unicode создать, а старую как бекап оставить ;)

 

Endy, у вас сейчас через phpmyadmin база читается вообще? Может быть данные изначально не распознаются mysql (но декодируются форумом)?

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Endy, у вас сейчас через phpmyadmin база читается вообще? Может быть данные изначально не распознаются mysql (но декодируются форумом)?

 

Нет, не читается. Ни оригинальная база (в latin1), ни конвертированная (utf8) Через myadmin обе видны как кракозяблы.

Т.е. 3 версия не может распознавать, то что могла 2я? Это как-то лечится?

Или это проблема в конфигурации mysql сервера?

Изменено пользователем Endy
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Ага! Кракозяблы уже изначально в базе!

 

Собственно, поэтому при экспорте данных в файл, либо при конвертировании средствами самого mysql, данные и теряются.

 

А вот таким запросом выведет правильно, или снова закорюками?

SELECT CONVERT(CONVERT(CONVERT(post USING cp1251) USING binary) USING utf8) FROM ibf_posts LIMIT 0, 10

 

И вот таким:

SELECT CONVERT(CONVERT(CONVERT(post USING latin1) USING binary) USING utf8) FROM ibf_posts LIMIT 0, 10

Ссылка на комментарий
Поделиться на других сайтах

  • 0

В первом случае вывелось знаками вопросов. А во втором вроде вопросов и кракозяблов нет, но вывод только такой

 

<b><i>

 

Кроме этих двух тегов ничего не вывелось.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Endy, нужно разбираться на месте. Обратитесь к саппорту и заплатите им за обновление, а так мы можем долго провозиться - уж слишком сложная ситуация у вас.
Ссылка на комментарий
Поделиться на других сайтах

  • 0
P(A), он раньше писал, что делал дамп и конвертировал через iconv... Сдается мне, уже процесс экспорта (с дефолтными параметрами) портил данные...
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Сдается мне, уже процесс экспорта (с дефолтными параметрами) портил данные...

С дефолтными да. Поэтому и нужен запрос character_set к текущей базе, что бы понять, что выставить в параметре --default-character-set=?

 

Все равно тех поддержка раньше понедельника может не ответить.

Изменено пользователем P(A)
Ссылка на комментарий
Поделиться на других сайтах

  • 0
P(A), ладно, признаюсь, я просто сдался :D Конечно, если самому через ssh на сервер зайти - надо минут пять чтобы все выяснить и проверить, а вот так на форуме, по одной команде в час выяснять - никакой воли не хватит ;) Потому саппорт и предлагаю :)
Ссылка на комментарий
Поделиться на других сайтах

Гость
Эта тема закрыта для публикации сообщений.
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.