Перейти к содержимому
Калькуляторы

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

А может и не 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'а ответ.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.