Error при апгрейде на 3.3.4

Подписчики

29 августа 201213 г

Делаю "репетицию" апгрейда с 2.0.0 на свежий 3.3.4 (лицензионный!!!!! )

Процесс застревает на следующем этапе:

доходит до вырубания на тайм-ауте

откатил всё назад. увеличил параметры таймаута до 900 секунд

погнал сначала и та же фигня (естественно до вырубания на таймауте прошло больше времени)

Плз срочнаааа пАмагите новичьку!!!!!

Что делать?

Где копать?

P.S. делал поиск на "16 запросов" и "16 queries". Безрезультатно

29 августа 201213 г

Если форум большой - выполняйте SQL-запросы вручную. У мастера обновления есть и такой режим.

29 августа 201213 г

Что делать?
Где копать?

1. Вниматочно прочитать вот это: http://wiki.iblink.ru/ipb3/upgrade

2. Убедиться в соответствие настроек сервера требованиям дистрибутива.

3. Включить sql_debug в conf_global.php, скопировать сюда ошибки...

И, по моим наблюдениям, обновление со второй версии скрипта сразу до 3.3.4 ни у кого не получается, что то там накосячил IPS с модулем апгрейда, какие то он нереальные таблицы запрашивает... Править его руки не дошли, поскольку нормально проходит обновление в два этапа, на 3.2.3 и потом 3.3.4.

Офтоп: Я бы лично на 3.2.3 остановился - самая безпроблемная и стабильная версия на сегодняшний день. Это, опять же, имхо.

29 августа 201213 г

Автор

1. Вниматочно прочитать вот это: http://wiki.iblink.ru/ipb3/upgrade
2. Убедиться в соответствие настроек сервера требованиям дистрибутива.
3. Включить sql_debug в conf_global.php, скопировать сюда ошибки...

И, по моим наблюдениям, обновление со второй версии скрипта сразу до 3.3.4 ни у кого не получается, что то там накосячил IPS с модулем апгрейда, какие то он нереальные таблицы запрашивает... Править его руки не дошли, поскольку нормально проходит обновление в два этапа, на 3.2.3 и потом 3.3.4.

Офтоп: Я бы лично на 3.2.3 остановился - самая безпроблемная и стабильная версия на сегодняшний день. Это, опять же, имхо.

начнём с того, что вышеуказанное пособие изучено мною досконально и отнюдь не по диагонали.

А Ваш ответ (по всем трём пунктам, наблюдениям и офтопу) наводит сомнения что Вы действительно поняли мой вопрос.

соответствие настроек сервера проверяется на начальном этапе установки.

sql_debug в conf_global.php - ни к чему! нету SQL Errors

просто очень долгое исполнение.

и самое главное что Вы пропустили - это то, что всё это происходит на этапе апдейта с 2.1.7 до 2.2.0 (Это чётко видно из приложенного скриншота). Отсюда рекомендации апдейтиться сначала до 3.2.3 выглядят бессмысленными

Ritsuka ответил по существу. Спасибо. Жаль что нет более гуманных решений. Ибо между 2.0.0 и 3.3.4 было около сотни (если не больше) промежуточных версий. и на каждый апдейт есть по несколько сетов с запросами. Геморно как то. Но попробую.

29 августа 201213 г

Ritsuka ответил по существу. Спасибо. Жаль что нет более гуманных решений. Ибо между 2.0.0 и 3.3.4 было около сотни (если не больше) промежуточных версий. и на каждый апдейт есть по несколько сетов с запросами. Геморно как то. Но попробую.

Я как-то целые выходные обновлял один форум с базой в 30+ Гб с 2.х.х до 3.х вручную, вот это было действительно геморно.

Заметил, что очень хорошо помогает временное отключение индексов для всех таблиц перед запуском конвертера:

ALTER TABLE ... DISABLE KEYS

Чтобы потом, по завершению работ, включить:

ALTER TABLE ... ENABLE KEYS

Для себя писал небольшой скриптик:

<?php

include("conf_global.php");

$dbhost = $INFO['sql_host'];
$dbuser = $INFO['sql_user'];
$dbpass = $INFO['sql_pass'];
$dbname = $INFO['sql_database'];

$dbconn = mysql_connect($dbhost, $dbuser, $dbpass) or die( mysql_error() );
$db = mysql_select_db($dbname) or die( mysql_error() );

$sql = 'SHOW TABLES';
$result = mysql_query($sql) or die( mysql_error() );

while ( $row = mysql_fetch_row($result) )
{
 $table = mysql_real_escape_string($row[0]);
 $sql = "ALTER TABLE $table DISABLE KEYS"; //ENABLE
 mysql_query($sql) or die( mysql_error() );
}
mysql_close($dbconn);
echo "ok";

С включенными индексами конвертирование таблицы из 6 млн постов занимало около 6 часов, после выключения - порядка 10 минут. Причем длительность процесса с ростом количества постов растет с геометрической прогрессией.

Ну и всегда есть вариант с выполнением всего процесса на другой, более мощной машине :)

29 августа 201213 г

начнём с того, что вышеуказанное пособие изучено мною досконально и отнюдь не по диагонали.

А Ваш ответ (по всем трём пунктам, наблюдениям и офтопу) наводит сомнения что Вы действительно поняли мой вопрос.

Да уж, где нам убогим...

и самое главное что Вы пропустили - это то, что всё это происходит на этапе апдейта с 2.1.7 до 2.2.0 (Это чётко видно из приложенного скриншота). Отсюда рекомендации апдейтиться сначала до 3.2.3 выглядят бессмысленными

Я, собственно, пытался сказать что секции upgrade.php относящиеся к апдейту 2.3.5 -> 2.3.6 -> 3.0 (более старых скриптов мне обновлять не приходилось пока) в версии 3.3.4 работают не корректно, проблема решилась обновлением в 2 этапа с использованием апдейтера от версии 3.2.3. Два раза с этим сталкивался. И кто может поручиться, что в ней нет ошибок и на этапе, где Вы застряли?

Что до размеров базы, то моя весила 70 мегабайт упакованная по максимуму.

Никакого особенного гемороя с ручными запросами я не заметил, не так их и много было...

1 сентября 201213 г

Автор

Фишка с DISABLE KEYS помогает. Ritsuka, респект.

По моим личным наблюдениям и личным опытом (небольшим, но тем не менее) - апдейт должен производиться автоматически.

Теперь о кодировке.

у меня категорически отторгается фишка с прописанием в conf_global.php

$INFO['sql_charset']			=	'utf8';

Делал так:

Снять дамп в utf8

Создать новую базу и прописать её в conf_global.php

RUN IN SQL : ALTER DATABASE newDBname DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci

Импортировать сконвертированный дамп в новую базу с кодировкой utf8

RUN IN SQL : ALTER DATABASE newDBname DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci (на всякий случай, после импорта полез в таблицу и вижу что там сравнение с cp1251)

DISABLE KEYS (script by Ritsuka)

./admin/upgrade

ждать…

Админка / Settings: Server Environment. Change to UTF-8

При таком варианте кириллица переносится нормально

до этого пробовал вариант с дампом в cp1251, конвертацией через iconv + 2 замены sed - был косяк с буквой И

добавить в conf_global.php $INFO['sql_charset'] = 'utf8'; не помогало. был fatal error до тех пор пока не убрал.

варианты с досрочным прописанием $INFO['sql_charset'] = 'utf8'; (то есть в точности с мануалом не прокатывали никак. Сплошные кракозябры.

Нерешённые пока траблы:

Личные сообщения во время апгрейда я не конвертировал. Чтоб не ждать лишние полтора часа не зная получится ли нормально кириллица.

Прогнал конвертирование позже из админки и получилась лажа с буквой И.

Далее, сделал импорт русского языка - и всё где есть буква И - тоже вышло косо

Обидно, думал что с апгрейдом базы разобрался более менее

Всё же что то где то не так....

в .htaccess прописано

AddDefaultCharset utf-8

AddCharset utf-8 *

CharsetSourceEnc utf-8

CharsetDefault utf-8

</IfModule>

Где ещё копать?

Изменено 1 сентября 201213 г пользователем Boris

1 сентября 201213 г

Автор

UPDATE

при выборе нового скина там всё перекешировывается всё и даже в постах вместо нормальной буквы И появляется ромбик с вопросом :angry:

1 сентября 201213 г

Копать надо в эту сторону http://forum.maxsite.org/viewtopic.php?id=175#p619

1 сентября 201213 г

Автор

Тот вариант не прокатит.

Там рекомендуется в my.cnf прописать default-character-set = utf8

MySQL не сможет рестартнуться. Я имел это счастье когда переносил двушку на VPS. Пока не закомментировал default-character-set (там было 1251) - МуСКЛ не рестартился и были знаки вопроса

Но раз пошла такая пьянка, то возможно что то другое в my.cnf мешает:

[mysqld]
character-set-server=cp1251
collation-server=cp1251_general_ci
init-connect="SET NAMES cp1251"
skip-character-set-client-handshake

скорее всего что то из этих параметров мешает.

подчеркну, в самой БД всё прописано правильно. и кодировка и сравнение.

траблы возникают во время кеширования и апдейтов. то есть где то настройки мусклсервера задавливают прописанное в самой базе

Вопросы:

1) Что из них менять? Что вообще убрать?

2) На каком этапе это всё делать: до импорта базы, после импорта, но перед апгрейдом, после апгрейда?

Изменено 1 сентября 201213 г пользователем Boris

1 сентября 201213 г

Я не имел ввиду конкретно какой-то вариант, я подразумевал что нужно отталкиваться в нужную сторону исходя из причины.

1 сентября 201213 г

Автор

И ещё.

Если кому то это о чём то говорит, то проблема только с буквой И.

Буква ш - абсолютно нормально.

Хотя везде, где я гуглил то проблема была с двумя буквами.

Я думаю всё же настройки my.cnf виноваты. Может Ritsuka подскажет что именно там задавливает прописанное в базе?

1 сентября 201213 г

У вас же старая оригинальная база двойки нетронутая лежит?

1. Сделайте копию той БД в пределах сервера (например, через phpmyadmin),

2. Полностью сконвертируйте эту копию в utf8 средствами MySQL,

3. Поправьте в my.cnf:

init-connect="SET NAMES utf8"

4. (опционально) Отключайте индексы,

5. Конвертируйте, подключив к тройке эту копию.

2 сентября 201213 г

Автор

Боюсь рано радоваться, но похоже прокатило.

Более того, мне этот вариант кажется более оптимальным по времени

Большое спасибо, Ritsuka

Сам скрипт отрубился на таймауте.

Тогда использовал так называемое Дополнение к способу Ritsuka для больших баз

Но и тут первая попытка вышла криво.

Копнув, я понял что сама база конвертируется в utf_unicode_ci, а таблицы по отдельности utf_general_ci

и от этого видимо переколбасило

утром я изменил скрипт для ssh. и саму базу тоже попросил конвертировать в utf_general_ci

вроде работает. на данный момент конвертируются PM

Если в скрипте disable keys написать enable и запустить - обрубается на таймауте.

Можно как то запустить в ssh одной командой или надо писать скрипт для всех таблиц наподобие того как конвертировалась база?

2 сентября 201213 г

Почему не добавить в скрипт

ignore_user_abort(true);
set_time_limit(0);

если конфиг позволяет?

Запуск php скрипта в фоновом режиме - http://habrahabr.ru/post/137337/.

2 сентября 201213 г

Если в скрипте disable keys написать enable и запустить - обрубается на таймауте.

Бгг. А вы все скрипты запускайте через ssh :)

В директории форума команда:

$ php имя_скрипта.php

Никакие таймауты будут вам не страшны. Скрипты адаптированы под универсальное использование - и конвертер, и "включалка" индексов. Таймаут из-за того, что "включение" сопровождается перестроением полных индексов для всех таблиц.

Создайте аккаунт или войдите в него для комментирования

Зарегистрировать аккаунт

Войти сейчас

Подписчики

Перейти к списку тем

Error при апгрейде на 3.3.4

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

Создайте аккаунт или войдите в него для комментирования

Аккаунт

Навигация

Поиск

Настроить push-уведомления браузера

Chrome (Android)

Chrome (компьютер)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (компьютер)

Firefox (Android)

Firefox (компьютер)