Justice 0 09/17/17 13:22 Хотел для себя прояснить- до апдейта на 3.0.5 у меня база была вся в MyIsam (по крайней мере так было написано в колонке "тип" напротив всех таблиц), после- изменились ряд таблиц на InnoDB. Но как я понимаю, InnoDB не поддерживает полнотекстовый поиск (он доступен только начиная с версии MySQL 5.6.4, как написано в интернете) и вроде бы работает "хуже" для IPB (техподдержка IPB). 1. Так откуда взялась печаль InnoDB в базе? 3.0.5 сама переделала? Тогда зачем ругается на отсутствие полнотекстового поиска?2. Стоит ли сконвертировать всё в MyIsam (или Inno DB?)?3. Чем чревато игнорирование "The used table type doesn't support FULLTEXT indexes" при апдейте в последующей работе форумного движка? 4. Каким запросом можно точно выяснить тип таблиц в существующей базе (2.3.6) и сделать батч-конвертацию в тот или иной тип? Спасибо. Поделиться сообщением Ссылка на сообщение
Justice 0 09/17/17 15:37 По п.4 ответ нашел сам, работает: <?php $host = 'localhost';$log = 'логин';$pass = 'Пароль';$db = 'Имя базы'; mysql_connect($host,$log,$pass);mysql_select_db($db); $q = mysql_query("SHOW TABLES");while ($table = mysql_fetch_array($q)){ mysql_query("ALTER TABLE `".$table['Tables_in_'.$db]."` ENGINE = InnoDB");} ?> Поделиться сообщением Ссылка на сообщение
Огурчик 0 03/04/21 17:24 Сам столкнулся с той же проблемой, и всетаки нашел решение здесь спасибо) Поделиться сообщением Ссылка на сообщение
Vlad777 0 10/02/24 21:12 23.12.2009 в 21:21, Ph-A сказал: Берем дистрибутив IPB 3.x Любой? В сети читал, что надо самый первый из линейки. 23.12.2009 в 21:21, Ph-A сказал: Гайд по обновлению до 3x - Обновление форума IP.Board до версии 3 По ссылке пустая страница - ни сообщения об ошибке, ни другого текста. Совсем пусто. Поделиться сообщением Ссылка на сообщение
Lesovsky 175 10/02/24 21:25 11 минут назад, Vlad777 сказал: Любой? В сети читал, что надо самый первый из линейки. Можно с помощью версии IPB 3.0.5 или сразу последний IPB 3.4.9 в них есть необходимые скрипты по обновлению с предыдущих версий. 11 минут назад, Vlad777 сказал: По ссылке пустая страница - ни сообщения об ошибке, ни другого текста. Совсем пусто. В курсе, к сожалению, после обновления этот раздел не обновил, т.к. эти статьи уже музейные, если нужно, то вот её содержимое: Скрытый текст В IP.Board 3 было сделано много существенных изменений в архитектуре приложения. Одним из самых больших нововведений стала работа форума с UTF-8. При обновлении вашего старого форума до версии 3, вам скорее всего прийдется столкнуться с необходимостью сконвертировать вашу старую базу в новую (в формате UTF-8). Данная инструкция поможет сделать шаг за шагом. Шаг 0. Готов ли ты к переходу? Прежде чем грезить о переходе на новый форум, необходимо узнать, сможет ли сервер работать с ним. Для оценки существующей конфигурации PHP, создаем в корневой директории старого форума файл myinfo.php с содержимым Запускаем скрипт в браузере. Результатом будет табличка следующего вида: Во-первых, версия PHP - она должна быть 5.1.x, а лучше 5.2.x, если версия PHP 4.x.x или PHP 5.3.x, форум у вас работать не будет. Во-вторых, новому IP.Board 3 нужны модули расширения PHP: dom gd iconv libxml mbstring mysqli или mysql Reflection SimpleXML SPL Ищите эти модули поиском по странице. Если одного из выше перечисленных модулей не будет - форум не будет работать. В-третьих, крайне желательно наличие следующих модулей: json sockets sphinx XCache или APC Данные модули позволяют оптимизировать работу форума, но они не обязательны для его работы. В-четвертых, память выделенная для PHP. Найдите значение memory_limit в таблице на странице. Оно должно быть не менее 32M, идеально 128M, значение надо смотреть в первой колонке (Local Value). Если памяти будет меньше, то форум не сможет нормально обновиться, возникнут проблемы с импортированием стилей, настроек и языков. Итак, если все условия выполнены - мы готовы к обновлению. Приступим... Шаг 1. Подготовка. Прежде чем начинать что-то делать, необходимо подготовить пути отступления на случай непредвиденных ситуаций. Здесь нам крайне помогут следующие инструменты: SSH / SypexDumper FTP Для обладателей SSH Делаем резервную копию базы данных: Получаем всю информацию о соединении с БД > cat ./mydomain.ru/htdocs/forums/conf_global.php | grep sql $INFO['sql_driver'] = 'mysql'; $INFO['sql_host'] = 'server.mysql'; $INFO['sql_database'] = 'db_forum'; $INFO['sql_user'] = 'db_user'; $INFO['sql_pass'] = 'db_passw'; $INFO['sql_tbl_prefix'] = 'ibf_'; $INFO['sql_debug'] = '1'; $INFO['mysql_tbl_type'] = 'MyISAM'; $INFO['mysql_codepage'] = 'cp1251'; Путь до conf_global.php у вас конечно будет свой. Здесь все данные для наглядности, у вас они будут другими! Теперь когда данные нам известны делаем резервную копию базы > mysqldump -h server.mysql -u db_user -p db_forum --default-character-set=cp1251 > dump.sql И сделаем сразу архивчик > tar -czf dump.tar.gz dump.sql Для обладателей SypexDumper Подробная инструкция по использованию Шаг 2. Новые файлы. Теперь необходимо закачать новые файлы форма на сервер. Для этого в начале разберемся со старыми. Часть из них нам больше уже не понадобиться никогда. Потому удаляем следующие директории и файлы: ./sources ./skin_acp ./retail ./resources ./modules ./lofiversion ./jscripts ./ips_kernel ./interface ./install ./init.php ./index.php ./favicon.ico ./converge_local ./admin.php ./admin Должны остаться следующие файлы и директории: ./uploads ./style_images ./style_emoticons ./style_captcha ./style_avatars ./conf_global.php ./cache Теперь берем дистрибутив форума, и все файлы и директории из папки upload закачиваем на сервер при помощи FTP-клиента. Должно получиться так ./xml.php ./uploads ./style_images ./style_emoticons ./style_captcha ./style_avatars ./robotstxt.txt ./retail ./public ./lofiversion ./ips_kernel ./interface ./initdata.php ./index.php ./hooks ./favicon.ico ./converge_local ./conf_global.php ./cache ./admin Теперь нужно проверить, что все права на директории расставлены правильно. IP.Board 3 требует записи в следующие директории ./cache ./cache/tmp ./cache/lang_cache ./cache/lang_cache/1 ./cache/skin_cache ./public/style_images ./public/style_css ./hooks ./uploads И файл ./conf_global.php Для того чтобы не было проблем выставляем этим директориям и файлу CHMOD 777 (rwxrwxrwx). Шаг 3. Подготовка к обновлению. Кодировка в conf_global.php Ваш старый conf_global нужно изменить, чтобы обновление прошло успешно. Допустим сейчас он выглядит так Нам необходимо указать кодировку соединения с базой данных, что бы ее понял новый форум. Для этого после строчки $INFO['sql_tbl_prefix'] = 'ibf_'; Добавляем $INFO['sql_charset'] = 'utf8'; Строчку $INFO['mysql_codepage'] = 'cp1251'; Можно удалить за ненадобностью. Перекодирование базы данных Это очень важный этап. Если его выполнить неверно, дальнейшее обновление форума не будет иметь смысла. Основная идея перекодирования базы У нас есть резервная копия базы в файле. Это простой текст в кодировке windows-1251 (cp1251). Для того чтобы перевести этот текст в UTF-8, необходимо воспользоваться конвертером (редактор текста с поддержкой перекодирования, утилита для перекодирования; все что угодно, что может перевести текст из Windows-1251 в UTF-8). После того как текст переведен в UTF-8, необходимо поправить инструкции в этом тексте, чтобы сама база работала с ним как с UTF-8. А именно есть две команды SET NAMES и DEFAULT CHARSET. На базе cp1251 они выглядят так SET NAMES cp1251 ) ENGINE=InnoDB DEFAULT CHARSET=cp1251 В нашей резервной копии таких команд больше чем две. Значит нам нужно их заменить во всем файле на SET NAMES utf8 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 Перекодирование средствами SSH Воспользуемся утилитой iconv для преобразования нашей резервной копии (которую мы делали на первом шаге), делается это так: >iconv -f cp1251 -t utf8 dump.sql > dump.utf8 Назначение ключей следующее: -f cp1251 – конвертировать из кодировки cp1251 -t utf8 – в кодировку utf8 dump.sql – файл который надо сконвертировать > dump.utf8 – результаты конвертации запишутся сюда Возможно появление проблем при конвертации, которые прервут процесс конвертирования. Это как правило происходит из-за невозможности найти соответствие символов одной кодировки в символы другой. В таких случаях стоит добавить еще один ключ (-c) в вызов iconv. Т.е. команда будет выглядеть уже так: >iconv -c -f cp1251 -t utf8 dump.sql > dump.utf8 В этом случае при возникновении проблемы при конвертировании, символ будет пропущен, а конвертирование продолжится. Итак весь текст у нас переведен в UTF-8, теперь необходимо изменить команды SQL. Делается это так Собственно так как дамп у нас должен быть в правильной cp1251 кодировке, то делаем замену в файле этих значений на новые: > sed 's/SET NAMES cp1251/SET NAMES utf8/g' 1.dump.utf8 > sed 's/DEFAULT CHARSET=cp1251/DEFAULT CHARSET=utf8/g' dump.utf8.sql Данную команду наглядно описать с русскими значениями: sed 's/БЫЛО/СТАЛО/g' КУДА ЗАПИСЫВАЕМ Перекодирование подготовленным SypexDumper В директории Tools дистрибутива мы расположили скрипт измененного SypexDumper, который уже настроен на работу с базой вашего форума. Необходимо закачать данный скрипт в корневую директорию форума на сервере и запустить. Вводите данные для доступа к базе форума в первом окне. В следующем окне вам будет предложено сделать дамп базы и восстановить базу из резервной копии. Делаете дамп базы. После завершения dumper напишет, что резервная копия готова и даст ссылку на ее скачивание. Скачивать не надо. Просто заходим по FTP на сервер форума и убеждаемся, что копия действительно сделана и находится в директории cache. Вы можете скачать этот дамп к себе на компьютер. Запомните имя файла резервной копии. Возвращаемся к форме дампера из которой вы начали делать резервную копию. Теперь в нем необходимо выбрать восстановление базы. В первом выпадающем списке выбираете вашу базу данных, во втором - название файла резервной копии. Запускаете восстановление. После того как восстановление будет завершено. При помощи phpMyAdmin или схожего по возможности инструмента, проверяете, что все таблицы теперь имеют сравнение utf8_general_ci, и все данные внутри таблиц нормально отображаются. Другие способы Конвертирование посредством самого MySQL http://forums.ibresource.ru/index.php?showtopic=58417 от Ritsuka Дополнение к способу Ritsuka для больших баз Если скрипт подвисает на конвертировании базы, в основном на таблице posts, то необходимо воспользоваться модифицированным скриптом и SSH. Загружаете следующий скрипт в корневую директорию форума: Запускаете скрипт через браузер. Вы получите список инструкций для выполнения в mysql. Копируете код страницы в файл, например win2utf.sql, и закачиваете данный файл на сервер. Запомните путь к файлу, для примера у нас будет путь /home/user/htdocs/ Заходите на сервер с использованием SSH и выполняете следующую команду: mysql -uusername -p dbname Имя пользователя username, имя базы dbname и путь до файла sql запросов у вас должны быть свои. Вводите пароль и ожидаете завершения работы команды mysql. Использование специального Perl скрипта Метод исключительно для SSH. Скачиваете скрипт wget http://www.pablowe.net/convert_charset Выставляете ему права на запуск chmod a+x convert_charset Запускаете конвертацию базы форума в тестовом режиме ./convert_charset --database=database --host=localhost --user=username --askpass --test В консоль будут выведены команды, которые будет выполнять скрипт. Убедитесь, что все таблицы базы будут сконвертированы. Если скрипт не сможет найти таблицы, выполните следующую команду: mysql -u username -pDBUSERPASSWORD -e 'SHOW TABLES' database | awk '{if (NR>1) {if (NR==2) {a=$1} else {a=a "," $1}} } END {print a}' Данные для username, DBUSERPASSWORD и database должны быть вашими. Вы получите список таблиц в базе, дальше этот список необходимо добавить к ключу –tables ./convert_charset --database=database --host=localhost --user=username --askpass --tables=admin_login_logs,admin_logs,admin_permission_rows,announcements,.... --test Убедившись, что все таблицы будут затронуты, запустите команду без ключа –test Восстановление новой базы данных Наша база сконвертирована и готова к обновлению. Однако ее еще надо восстановить на сервере MySQL. Сначала необходимо поменять кодировку старой базы. При наличии SSH >mysql -u db_user -p db_forum -e 'ALTER DATABASE db_forum DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci' Enter password: > При отсутствии SSH В любом доступном интерфейсе для работы с базой данных (например, phpMyAdmin) перейти в базу форума и выполнить запрос ALTER DATABASE db_forum DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci Вместо db_forum должно быть название ваше базы! Теперь развернем базу. Делается это так: При наличии SSH >mysql -u db_user -p --default-character-set=utf8 db_forum При отсутствии SSH Восстанавливать лучше SypexDumper. Закидываете сконвертированную резеврную копию в директорию, куда SypexDumper сохраняет резервные копии баз. И запускаете SypexDumper. Внимательно следуете инструкциям Дамп развернут, кодировка базы utf8, база готова для обновления. Шаг 4. Обновление Теперь у нас все готово, чтобы запустить скрипт обновления. Заходите браузером на страницу http://mydomain.ru/forum/admin/upgrade/ и следуете указаниям мастера обновления. Шаг 5. Ошибки после обновления Кодировка страниц Бывает так, что после обновления, зайдя на страницу форума, вы видите что-то подобное: Проблема в том, что выбирается не правильная кодировка для страниц. Проверьте в АЦ параметр Кодировка страниц форума (АЦ → Системные настройки → Настройки серверного окружения → Кодировка страниц форума) он должен содержать значение utf-8. Если все правильно, попробуйте создать файл .htaccess в корневой директории сервера, со следующим содержанием: AddDefaultCharset utf-8 AddCharset utf-8 * CharsetSourceEnc utf-8 CharsetDefault utf-8 Не все символы выводятся При просмотре страницы форума, часть символов пропала, а вместо них ромбики: Причины может быть две: 1. Вы забыли изменить conf_global.php так как об этом писалось в шаге 1. Попробуйте выполнить эти изменения, если не поможет внимательно повторите обновление. 2. Вы сконвертировали базу, которая уже была в UTF. Начните обновление с шага 2, но не выполняйте перекодирование базы (самого текста), а только выполните замены команд SQL. 1 Поделиться сообщением Ссылка на сообщение
