UTM5 5.2.1-005

[Lex]

Как это делать, я писал ранее на форуме.

это вот так ? viewtopic.php?p=30005&highlight=%E1%E0% ... 0%F2#30005

Нет. Искать не буду, напишу по новой. Нужно оформить письмо на адрес электронной почты supinfo@netup.ru. В письме нужно указать название организации, контактное лицо, краткое описание проблемы (в двух-трех предложениях), полное описание проблемы (словами, по шагам, что делаете, что получаете, что ожидали получить), необходимая для диагностики проблемы техническая информация(лог-файлы, дампы базы, вывод в консоль и т.д), либо ссылки на эту информацию, если её суммарный объем более 10Мб. Срок рассмотрения баг-репорта от двух недель.

[georg]

Не знаю как у кого, но у меня при заливке UTM5_MYSQL_update.sql сервер просто вываливается и перезагружается...
Вначале говорит:
ERROR 1064 (42000) at line 178: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'status_type int default '0'' at line 1
... так на несколько строчек, а затем:
ERROR 2013 (HY000) at line 559: Lost connection to MySQL server during query
ERROR 2006 (HY000) at line 560: MySQL server has gone away
ERROR 2006 (HY000) at line 561: MySQL server has gone away
ERROR 2006 (HY000) at line 562: MySQL server has gone away
В логах MySQL:
InnoDB: Error: MySQL is trying to perform a consistent read
InnoDB: but the read view is not assigned!
ALTER TABLE system_accounts ADD COLUMN id int(11) NOT NULL auto_increment PRIMARY KEY
071214 20:46:47InnoDB: Assertion failure in thread 2709331968 in file row0sel.c line 3500

Если вводить данные построчно из шэла в mysql отвечает следующее:
mysql> CREATE TABLE IF NOT EXIST system_accounts (int zzzzz);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'EXIST system_accounts (int zzzzz)' at line 1
mysql> ALTER TABLE system_accounts ADD COLUMN id int(11) NOT NULL auto_increment PRIMARY KEY;
ERROR 2013 (HY000): Lost connection to MySQL server during query

mysql-server-5.0.51 ставил с опциями WITH_CHARSET=utf8 WITH_XCHARSET=all WITH_COLLATION=utf8_general_ci
Залил в него бэкап с рабочего сервера...

Это только у меня такие глюки?

[georg]

И ещё, может кто-то сможет подсказать как будет вести себя utm5_core если я ему в конфиге пропишу количество попыток соединения с sql сервером например 65000, с timeot'ом в 60 секунд и, в процессе работы utm5_core положу mysql-server?
Как долго он сможет держать в себе накопленные и накапливаеммые данные и как много?

[Lex]

И ещё, может кто-то сможет подсказать как будет вести себя utm5_core если я ему в конфиге пропишу количество попыток соединения с sql сервером например 65000, с timeot'ом в 60 секунд и, в процессе работы utm5_core положу mysql-server?
Как долго он сможет держать в себе накопленные и накапливаеммые данные и как много?

Нормально поведет, но лучше так не делать. Данные будет накапливать до тех пор пока память не кончится.

[MoHaX]

Поставил 5 билд. Поудалял у некоторых пользователей тарифы, привязал новые, перегрузил ядро. И опять в verificator.log наблюдаю

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

-- WARNING slink 86 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=86;

-- WARNING slink 86 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=86;

-- WARNING slink 29 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=29;

-- WARNING slink 29 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=29;

-- WARNING slink 143 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=143;

Может я чего не понял, но после прочтения

11. исправлена ошибка, в результате которой при удалении сервисной связки не помечались как удаленные записи в таблицах dtagg_iptraffic, dtagg_periodic, dtagg_hotspot и dtagg_telephony, что приводило к некритическому нарушению логической целостности базы данных (mantis id 879, 880);

я думал, что этого быть не должно... Что бы это значило?

[Lex]

Поставил 5 билд. Поудалял у некоторых пользователей тарифы, привязал новые, перегрузил ядро. И опять в verificator.log наблюдаю

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

-- WARNING slink 86 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=86;

-- WARNING slink 86 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=86;

-- WARNING slink 29 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=29;

-- WARNING slink 29 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=29;

-- WARNING slink 143 exists only in dtagg_iptraffic
-- SQL DESC check slink exists and delete dtagg_iptraffic entry for deleted slink
UPDATE dtagg_iptraffic SET is_closed=1 WHERE slink_id=143;

Может я чего не понял, но после прочтения

11. исправлена ошибка, в результате которой при удалении сервисной связки не помечались как удаленные записи в таблицах dtagg_iptraffic, dtagg_periodic, dtagg_hotspot и dtagg_telephony, что приводило к некритическому нарушению логической целостности базы данных (mantis id 879, 880);

я думал, что этого быть не должно... Что бы это значило?

Одно из двух: или эти записи остались со старых сборок или где-то что-то при исправлении указанных проблем не учли. Если есть гарантированный способ воспроизведения пишите багрепорт.

[Magnum72]

двух: или эти записи остались со старых сборок или где-то что-то при исправлении указанных проблем не учли. Если есть гарантированный способ воспроизведения пишите багрепорт.

Кто-то обещал "съесть свой паспорт"

[Chris]

[share]

ERROR 2013 (HY000) at line 559: Lost connection to MySQL server during query
ERROR 2006 (HY000) at line 560: MySQL server has gone away
ERROR 2006 (HY000) at line 561: MySQL server has gone away
ERROR 2006 (HY000) at line 562: MySQL server has gone away

У меня была похожая проблема. Мускул "уходил прочь" при апдейте и рестартился.
Решали проблему переустановкой мускула на mysql-server-5.1.11 с портов, и запуска з дєфолтовым кофигом.


Правда теперь другое выскочило

# /usr/local/etc/rc.d/utm5_core.sh start
Starting utm5_core
/libexec/ld-elf.so.1: Shared object "libssl.so.5" not found, required by "utm5_core"

# pkg_info
compat5x-i386-5.4.0.8_7 A convenience package to install the compat5x libraries
....
mysql-client-5.1.11 Multithreaded SQL database (client)
mysql-server-5.1.11 Multithreaded SQL database (server)
....
utm5-2.1.005 Universal Billing System for ISP
xorg-libraries-6.9.0 X11 libraries and headers from X.Org

Ставил также openssl-0.9.8g.
Где ещё копать?

--
FreeBSD 6.2

[am]

У меня была похожая проблема. Мускул "уходил прочь" при апдейте и рестартился.
Решали проблему переустановкой мускула на mysql-server-5.1.11 с портов, и запуска з дєфолтовым кофигом.

Если вылетает mysql, смотрите в его логи, скорее всего это из-за памяти. Мне помог просто запуск с конфигом по-умолчанию.

# /usr/local/etc/rc.d/utm5_core.sh start
Starting utm5_core
/libexec/ld-elf.so.1: Shared object "libssl.so.5" not found, required by "utm5_core"

ln -s libssl.so.4 libssl.so.5

[georg]

Запуск с дефолтным конфигом - это вы конечно хорошо пошутили... Зачем тогда многопроцессорность, куча оперативки и RAID массивы?
На 5.1 мускуле тоже пробовал - та же история...
Вылечилось заливкой полного mysqldump'а и переходом на кодировку utf8...
Так как UTM5 используем давно - база была в latin1, залил её, переконвертировал, update залился... Ругался на непонимание некоторых строк, подправил согласно замечаниям xore - тоже залился...
Так как UTM5 не дружит с FreeBSD amd64 решил разнести - mysql на одной машинке(FreeBSD 6.3 amd64,2*DualCore XEON,8GB RAM, 2TB RAID5 SATA) и utm5 на второй (FreeBSD 6.3 i386, 2*Xeon, 1GB RAM, 70GB SCSI).
Если кто-то делал такое - поделитесь, есть ли минусы, и пробывал кто-то такое на Solaris 10? А то есть большое желание...
Всё вроде завелось, но не видно расчётных периодов... В таблице они есть, админкой не показываются... Хотя пользователи считаются старыми расчётными периодами... Новые когда добовляю текущей датой - показываются, началом года - в таблицу добавляются, админкой не видятся... С этим кто-то сталкивался?

[dda2000]

georg

Таже ситуация, база в latin1, а конвертить рано или поздно придется. Не хотелось бы наступить на грабли от неправильной конвертации.
Расскажи подробнее как конвертил базу из latin1 -> utf8.

[georg]

EMS MySQL Manager - но, только что заметил, конвертировал не правильно... Русские буквы отображаются не правильно... Благо по русски вбивал только у двух пользователей и то... Информация эта не нужна...
Подскажите ещё - можно ли безпоследственно использовать utm5_optimizer или лучше всё-таки доучивать структуру базы и ручками... ?

[share]

Читал что для успешной смены кодировки на utf8, нужно конвертировать в порядке latin1 -> binary -> utf8.
А ещё лутше дампить сразу в utf8
Тема: Mysql

mysqldump --default-character-set=utf8

на практике сейчас и проверю.

[am]

Запуск с дефолтным конфигом - это вы конечно хорошо пошутили... Зачем тогда многопроцессорность, куча оперативки и RAID массивы?

Я не это имел ввиду, просто сказал, что дело, возможно, в настройках памяти мускула. Сам запускал на тестовой машине и после того, как всё запустилось, новую версию пока отложил...