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

 

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

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

 

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

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

 

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

Что делать?

Где копать?

 

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

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

Что делать?

Где копать?

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 остановился - самая безпроблемная и стабильная версия на сегодняшний день. Это, опять же, имхо.

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 было около сотни (если не больше) промежуточных версий. и на каждый апдейт есть по несколько сетов с запросами. Геморно как то. Но попробую.

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 минут. Причем длительность процесса с ростом количества постов растет с геометрической прогрессией.

 

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

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

 

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

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

 

и самое главное что Вы пропустили - это то, что всё это происходит на этапе апдейта с 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 мегабайт упакованная по максимуму.

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

Фишка с 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 *

<IfModule mod_charset.c>

CharsetSourceEnc utf-8

CharsetDefault utf-8

</IfModule>

 

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

Edited September 1, 201213 yr by Boris

UPDATE

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

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

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

Там рекомендуется в 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) На каком этапе это всё делать: до импорта базы, после импорта, но перед апгрейдом, после апгрейда?

Edited September 1, 201213 yr by Boris

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

И ещё.

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

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

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

 

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

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

 

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

 

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

 

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

init-connect="SET NAMES utf8"

 

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

 

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

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

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

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

 

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

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

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

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

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

 

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

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

 

 

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

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

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

ignore_user_abort(true);
set_time_limit(0);

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

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

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

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

 

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

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

 

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