Error при апгрейде на 3.3.4 - Дизайн и модификация Invision Power Board

Перейти к содержимому

 

Правила раздела

Здесь обсуждаются вопросы по настройке и администрированию форумов IPB 3.x.
Пожалуйста, не оффтопьте, если зашли сюда случайно, и обратите внимание на соседние разделы.
Установка, настройка и обслуживание форумов IPB 2.x.
Оформление форумов, включая верстку скинов.
Размещение рекламы на форумах.
SEO оптимизация форума.
Техническая поддержка наших скинов и модов.

СвернутьПрикрепленные теги

bb-коды

  • 3 Страниц +
  • 1
  • 2
  • 3

Error при апгрейде на 3.3.4 2.0.0 ==> 3.3.4

#1 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 29 Август 2012 - 12:10

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

Процесс застревает на следующем этапе:
доходит до вырубания на тайм-ауте

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

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

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

#2 Пользователь не на сайте   Ritsuka ответил: »

 
 
  • ***
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 1 908
  • Регистрация: 08-Июнь 09
  • Репутация: 531
  • IPB version:3.4.x
 

Отправлено 29 Август 2012 - 12:13

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

#3 Пользователь не на сайте   Dmitriy427 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Specialist
  • Сообщений: 574
  • Регистрация: 15-Октябрь 11
  • Репутация: 152
  • Откуда:Россия, Тула
  • IPB version:3.3.x
 

Отправлено 29 Август 2012 - 13:32

Просмотреть сообщениеBoris 29 Август 2012 - 12:10 сказал(а):

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

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

#4 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 29 Август 2012 - 15:40

Просмотреть сообщениеDmitriy427 29 Август 2012 - 13:32 сказал(а):

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

#5 Пользователь не на сайте   Ritsuka ответил: »

 
 
  • ***
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 1 908
  • Регистрация: 08-Июнь 09
  • Репутация: 531
  • IPB version:3.4.x
 

Отправлено 29 Август 2012 - 17:16

Цитата

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

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

#6 Пользователь не на сайте   Dmitriy427 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Specialist
  • Сообщений: 574
  • Регистрация: 15-Октябрь 11
  • Репутация: 152
  • Откуда:Россия, Тула
  • IPB version:3.3.x
 

Отправлено 29 Август 2012 - 21:59

Просмотреть сообщениеBoris 29 Август 2012 - 15:40 сказал(а):

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

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

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

Цитата

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

#7 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 01 Сентябрь 2012 - 14:44

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

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

Сообщение изменено: Boris (01 Сентябрь 2012 - 14:45)

0

#8 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 01 Сентябрь 2012 - 15:18

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

#9 Пользователь не на сайте   siv1987 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Skins Team
  • Сообщений: 8 745
  • Регистрация: 20-Март 09
  • Репутация: 2 276
  • IPB version:3.1.x
 

Отправлено 01 Сентябрь 2012 - 15:49

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

#10 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 01 Сентябрь 2012 - 16:27

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

Сообщение изменено: Boris (01 Сентябрь 2012 - 16:29)

0

#11 Пользователь не на сайте   siv1987 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Skins Team
  • Сообщений: 8 745
  • Регистрация: 20-Март 09
  • Репутация: 2 276
  • IPB version:3.1.x
 

Отправлено 01 Сентябрь 2012 - 16:32

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

#12 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 01 Сентябрь 2012 - 16:53

И ещё.
Если кому то это о чём то говорит, то проблема только с буквой И.
Буква ш - абсолютно нормально.
Хотя везде, где я гуглил то проблема была с двумя буквами.

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

#13 Пользователь не на сайте   Ritsuka ответил: »

 
 
  • ***
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 1 908
  • Регистрация: 08-Июнь 09
  • Репутация: 531
  • IPB version:3.4.x
 

Отправлено 01 Сентябрь 2012 - 18:04

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

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

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

3. Поправьте в my.cnf:
init-connect="SET NAMES utf8"


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

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

#14 Пользователь не на сайте   Boris ответил: »

 
 
  • Member
  • **
  • Смотреть галерею
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: Пользователи
  • Сообщений: 69
  • Регистрация: 15-Август 12
  • Репутация: 2
  • IPB version:3.3.x
 

Отправлено 02 Сентябрь 2012 - 11:25

Боюсь рано радоваться, но похоже прокатило.
Более того, мне этот вариант кажется более оптимальным по времени
Большое спасибо, Ritsuka

Сам скрипт отрубился на таймауте.
Тогда использовал так называемое Дополнение к способу Ritsuka для больших баз
Но и тут первая попытка вышла криво.
Копнув, я понял что сама база конвертируется в utf_unicode_ci, а таблицы по отдельности utf_general_ci
и от этого видимо переколбасило

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


Если в скрипте disable keys написать enable и запустить - обрубается на таймауте.
Можно как то запустить в ssh одной командой или надо писать скрипт для всех таблиц наподобие того как конвертировалась база?
0

#15 Пользователь не на сайте   Dmitriy427 ответил: »

 
 
  • Advanced
  • Insert nick to fast reply form
  • Quote selected text to fast reply form
  • Группа: IPB Specialist
  • Сообщений: 574
  • Регистрация: 15-Октябрь 11
  • Репутация: 152
  • Откуда:Россия, Тула
  • IPB version:3.3.x
 

Отправлено 02 Сентябрь 2012 - 15:31

Почему не добавить в скрипт
ignore_user_abort(true);
set_time_limit(0);
если конфиг позволяет?
Запуск php скрипта в фоновом режиме - http://habrahabr.ru/post/137337/.
0

Сообщить об этой теме:


  • 3 Страниц +
  • 1
  • 2
  • 3


Быстрый ответ

  

1 пользователей читают эту тему
0 зарегистрированных, 1 гостей, 0 скрытых


Контактная информация

Вопросы по работе сайта

+7 (917) 501-4765
C 10 до 20 в рабочие дни (время московское)

Техническая поддержка

Контактные данные специалистов

Дизайн форумов

IPB 3.x ¦ IPB 2.x

Бесплатные шаблоны

IPB 3.2 – 3.4 ¦ IPB 3.1 ¦ IPB 3.0 ¦ IPB 2.2 – 2.3 ¦ IPB 2.1 ¦ Клипарт
Лицензия на использование ¦ Ваша поддержка ¦ О проекте
Copyright © 2005-2016 IPBSkins.ru Team
При копировании материалов с сайта
прямая ссылка на источник обязательна