Пропали все ip адреса после обновления

Технические вопросы по UTM 5.0
Anton
Сообщения: 339
Зарегистрирован: Пт июл 01, 2005 10:57

Сообщение Anton »

Magnum72 писал(а):
hammer писал(а):Гмм.. и чё делать... ради чистоты эксперимента поставил 004 - залил ЭТОТ же бекап - все стартануло без верификатора и без проблемм. Вряд ли разработчики решили сделать подарок пользователям копаться руками в базе для запуска на 005 после 004... что то ещё должно быть -).
ЗЫ Бэк лился с 5 мускуля так и переливалсяв оного же.
у меня тоже такое было но помоему из-за того что мы забыли обновить таблицу periodic_service там поле добавилось новое с инвойсами связанное...
Что значит забыли?
Нетап написал инструкцию к обновлению, такое ощущение что он вынуждает чтобы все сидели на hotline

Anton
Сообщения: 339
Зарегистрирован: Пт июл 01, 2005 10:57

Сообщение Anton »

у кого стоит 4 мускул?
и 05 поставил без проблем

hammer
Сообщения: 286
Зарегистрирован: Сб янв 20, 2007 22:58
Контактная информация:

Сообщение hammer »

По факту вобщем это баг!.. хочет того netup или нет (може кто оформит в багрепорт =) )... хочет - пусть исправляет - а до тех пор всем пользователям совет сидеть на 004 иил на 003 или на чём есть - так ещё и не обновлятся, если не обновляется:). Ну если исправят - то это есть "+". Ну а на нет и суда нет!

ЗЫ. Изголялся с базой целый день - чё тока не делал - дамп нормально в пятерку не залился... Максимум чего достиг - новые глюки...

Anton
Сообщения: 339
Зарегистрирован: Пт июл 01, 2005 10:57

Сообщение Anton »

хотлайнюсь, надюсь что не буду отпечать дни рождения у заявки :)

Аватара пользователя
XoRe
Сообщения: 458
Зарегистрирован: Ср янв 10, 2007 16:04

Сообщение XoRe »

Я чуть ли не ручками все изменения в БД делал с 004 для 005.
Гемморно, но все заработало )

Аватара пользователя
Magnum72
Сообщения: 1947
Зарегистрирован: Чт сен 22, 2005 06:54
Контактная информация:

Сообщение Magnum72 »

XoRe писал(а):Я чуть ли не ручками все изменения в БД делал с 004 для 005.
Гемморно, но все заработало )
А я всегда ручками делаю :) сравниваю пре

Anton
Сообщения: 339
Зарегистрирован: Пт июл 01, 2005 10:57

Сообщение Anton »

ответ хотлайна
Не до конца применили скрипт UTM5_..._update.sql. Проблема с таблицей
system_accounts. Закомментируйте в скрипте строки, относящиеся к этой
таблице и
примените его снова.

все проперло, но есть не критичные ошибки, вообщем хотлайнить их буду пополную

Anton
Сообщения: 339
Зарегистрирован: Пт июл 01, 2005 10:57

Сообщение Anton »

все полет нормальный
ночью на главную поставил

polmax
Сообщения: 13
Зарегистрирован: Чт мар 01, 2007 17:10

Сообщение polmax »

Anton писал(а):ответ хотлайна
Не до конца применили скрипт UTM5_..._update.sql. Проблема с таблицей
system_accounts. Закомментируйте в скрипте строки, относящиеся к этой
таблице и
примените его снова.

все проперло, но есть не критичные ошибки, вообщем хотлайнить их буду пополную
А вот что происходит в базе:

Код: Выделить всё

InnoDB: Error: MySQL is trying to perform a consistent read
InnoDB: but the read view is not assigned!
TRANSACTION 0 106817, ACTIVE 0 sec, OS thread id 11276 starting index read, thread declared inside InnoDB 499
mysql tables in use 2, locked 1
1 lock struct(s), heap size 320
MySQL thread id 1, query id 560 localhost root setup
ALTER TABLE system_accounts  ADD COLUMN   id int(11) NOT NULL auto_increment PRIMARY KEY

080205 17:04:19InnoDB: Assertion failure in thread 11276 in file row0sel.c line 3500
InnoDB: Failing assertion: 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
080205 17:04:19 - mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=268435456
read_buffer_size=1044480
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 466543 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

080205 17:04:19  mysqld restarted

Так что если в логах появилось что то подобное, то
в файле UTM5_MYSQL_update.sql, надо закоментировать строки:

Код: Выделить всё

CREATE TABLE IF NOT EXISTS system_accounts  (zzzzz int);
ALTER TABLE system_accounts  ADD COLUMN   id int(11) NOT NULL auto_increment PRIMARY KEY;
ALTER TABLE system_accounts  ADD COLUMN   login varchar(255);
ALTER TABLE system_accounts  ADD COLUMN   password varchar(255);
ALTER TABLE system_accounts  ADD COLUMN   ip int default '0';
ALTER TABLE system_accounts  ADD COLUMN   mask int default '0';
ALTER TABLE system_accounts  ADD COLUMN   is_deleted int default '0';
ALTER TABLE system_accounts  DROP COLUMN zzzzz;
Вот что мне интересно, это у всех так или только у избранных?

Ответить