Странная работа FreeRadius (или MySQL...)

[grifin.ru]

А может и не FreeRadius, а MySQL, или даже ELTEX 2016 (прошивка 3.0.7)

 

Суть такая:

ELTEX шлет Accounting пакеты на три радиус сервера. Т.е. шлет-то он конечно на один, но у него прописаны три.

FreeRadius передает полученные в Radius пакете данные в одну из хранимых процедур MySQL (AddStartPacket(), AddUpdatePacket(), AddStopPacket())

Тексты процедур приводить не буду, скажу только AddStopPacket() добавляет стоповый пакет в таблицу "RawAcctSTOP" и удаляет ставшие ненужными записи о пакетах START и UPDATE из таблицы "RawAcct"

Есть некоторая процедуры, запускаемые по крону, которые выискивают звонки, по которым STOP не пришел (10 минут нет UPDATEов) и пишут такой звонок в таблицу "RawAcctSTOP" по данным последнего имеющегося UPDATE.

Для того, что бы избежать исключений вставка в таблицу сделана конструкцией INSERT IGNORE.

 

Получилось так, что из-за моих кривых рук одна из таблиц (которая хранит оперативные данные) не имила индекса и, при увеличении нагрузки операция с ней вылетала по таймауту, ну и лочила таблицу надолго. Из-за этого стоповый пакет не мог добавиться. Но вот что интересно...

INSERT IGNORE - должна делать игнор только если дубликат, если вставить неудалось из-за таймаута, то должно возникать исключение которое, в свою очередь, застравит хранимую процедуру вернуть ошибку радиусу, радиус должен сообщить об этом NASу (Элтексу) а тот, в свою очередь, отправить пакет на другой радиус сервер (Я говорил что их там три)

Так вот, этого почему-то не происходит.

Либо Ignore INTO игнорит и такие случаи тоже, либо я криво настроил FreeRadius и он не сообощает Элтексу о неудачной попытке внесения записи, либо Элтекс игнорирует (неправильно обрабатывает) полученный от radius'а ответ.

Есть у кого какие мысли на этот счет ?

[NiTr0]

INSERT IGNORE - должна делать игнор только если дубликат, если вставить неудалось из-за таймаута, то должно возникать исключение которое, в свою очередь, застравит хранимую процедуру вернуть ошибку радиусу, радиус должен сообщить об этом NASу (Элтексу)

не должно, просто коннект к радиусу отсыхает по таймауту. запрос к базе может выполняться и 10, и 20 минут.

 

 

а тот, в свою очередь, отправить пакет на другой радиус сервер (Я говорил что их там три)

Так вот, этого почему-то не происходит.

а это уже вопросы к разрабам элтекса - почему они при недоступности радиуса не шлют запрос на другие, а молча дуплят.

[grifin.ru]

Так вот и непонятно к кому вопросы.

Радиус работает START и UPDATE пакеты исправно складывались в базу, но для этого своя процедура и она не тупила.

А вот СТОП процедура складывающая СТОП пакеты тупила и отсыхала по таймауту.

При этом, очевидно, что MySQL сообщал вызвавшему его FreeRADIUS'у что процедура не была выполнена, а вот кто дальше затупил, элтекс или фрирадиус - это вопрос.

[NiTr0]

При этом, очевидно, что MySQL сообщал вызвавшему его FreeRADIUS'у что процедура не была выполнена

угу, через полчаса когда брас уже устал ждать ответа радиуса :)

 

а вот кто дальше затупил, элтекс или фрирадиус - это вопрос.

ни разу не вопрос.

 

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