grifin.ru Posted December 7, 2016 · Report post А может и не 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'а ответ. Есть у кого какие мысли на этот счет ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted December 7, 2016 · Report post INSERT IGNORE - должна делать игнор только если дубликат, если вставить неудалось из-за таймаута, то должно возникать исключение которое, в свою очередь, застравит хранимую процедуру вернуть ошибку радиусу, радиус должен сообщить об этом NASу (Элтексу) не должно, просто коннект к радиусу отсыхает по таймауту. запрос к базе может выполняться и 10, и 20 минут. а тот, в свою очередь, отправить пакет на другой радиус сервер (Я говорил что их там три) Так вот, этого почему-то не происходит. а это уже вопросы к разрабам элтекса - почему они при недоступности радиуса не шлют запрос на другие, а молча дуплят. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted December 7, 2016 · Report post Так вот и непонятно к кому вопросы. Радиус работает START и UPDATE пакеты исправно складывались в базу, но для этого своя процедура и она не тупила. А вот СТОП процедура складывающая СТОП пакеты тупила и отсыхала по таймауту. При этом, очевидно, что MySQL сообщал вызвавшему его FreeRADIUS'у что процедура не была выполнена, а вот кто дальше затупил, элтекс или фрирадиус - это вопрос. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted December 7, 2016 · Report post При этом, очевидно, что MySQL сообщал вызвавшему его FreeRADIUS'у что процедура не была выполнена угу, через полчаса когда брас уже устал ждать ответа радиуса :) а вот кто дальше затупил, элтекс или фрирадиус - это вопрос. ни разу не вопрос. радиус не ответил в установленное время. брас должен был решить, что радиус вообще недоступен (протокол-то - UDP) и пробовать следующий. но - затупил... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...