Проблема с RADIUS AcctSessionId (дублированный учёт).

Не обновляйте свои базы данных, используя RadSessionId, используйте RadUniqueID. В конфигурационном файле radius есть настройка, в которой можно указать, какие атрибуты использовать для создания этой уникальной хэш-суммы, чтобы она оставалась уникальной. Я использую acct_unique { key = “User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port” }. Пока что проблем не возникало.

Продолжение, все упустил в спешке этим утром… Данные учета нужно обрабатывать. Сидеть с таблицей учета, содержащей миллионы и миллионы записей, крайне неэффективно, потому что Radius должен выполнять запросы к этим данным, которые могут занять очень много времени. Создай еще две таблицы для себя…

```mysql
mysql> DESCRIBE RadiusAcctTotals;
+-----------------+-------------+------+-----+------------+----------------+
| Field           | Type        | Null | Key | Default    | Extra          |
+-----------------+-------------+------+-----+------------+----------------+
| TotAcctId       | bigint(21)  | NO   | PRI | NULL       | auto_increment |
| UserName        | varchar(64) | NO   | MUL | NULL       |                |
| AcctDate        | date        | NO   | MUL | 0000-00-00 |                |
| ConnNum         | bigint(12)  | YES  |     | NULL       |                |
| ConnTotDuration | bigint(12)  | YES  |     | NULL       |                |
| ConnMaxDuration | bigint(12)  | YES  |     | NULL       |                |
| ConnMinDuration | bigint(12)  | YES  |     | NULL       |                |
| InputOctets     | bigint(12)  | YES  |     | NULL       |                |
| OutputOctets    | bigint(12)  | YES  |     | NULL       |                |
+-----------------+-------------+------+-----+------------+----------------+
9 rows in set (0.02 sec)

mysql> DESCRIBE RadiusAcctMonthlyTotals;
+-----------------+-------------+------+-----+------------+----------------+
| Field           | Type        | Null | Key | Default    | Extra          |
+-----------------+-------------+------+-----+------------+----------------+
| MTotAcctId      | bigint(21)  | NO   | PRI | NULL       | auto_increment |
| UserName        | varchar(64) | NO   | MUL | NULL       |                |
| AcctDate        | date        | NO   | MUL | 0000-00-00 |                |
| ConnNum         | bigint(12)  | YES  |     | NULL       |                |
| ConnTotDuration | bigint(12)  | YES  |     | NULL       |                |
| ConnMaxDuration | bigint(12)  | YES  |     | NULL       |                |
| ConnMinDuration | bigint(12)  | YES  |     | NULL       |                |
| InputOctets     | bigint(12)  | YES  |     | NULL       |                |
| OutputOctets    | bigint(12)  | YES  |     | NULL       |                |
+-----------------+-------------+------+-----+------------+----------------+
9 rows in set (0.01 sec)
```

В рамках ежедневной процедуры обслуживания перемещай все данные учета из таблицы Radius Accounting, которые неактивны (имеют `acctstoptime`) и старше нескольких дней, в таблицы RadiusAcctTotals. Затем удаляй старые записи из таблицы Radius Accounting. Таким образом, основная таблица учета, используемая Radius, будет маленькой, компактной и не вызовет никаких проблем. Выполняются следующие шаги:

1.  Удаление записей старше 90 дней, так как они уже находятся в таблице AcctMonthlyTotals.
   ```mysql
   DELETE FROM RadiusAcctTotals WHERE AcctDate = '" . $Date_Start . "'
   ```
2.  Перемещение данных учета, закрытых за день, из таблиц Radius Accounting в обобщенную версию нашей собственной таблицы Accounting Data (мы делаем это на уровне пользователей, а не сессий, что уменьшает количество записей).
   ```mysql
   INSERT INTO RadiusAcctTotals (UserName, AcctDate, ConnNum, ConnTotDuration, ConnMaxDuration, ConnMinDuration, InputOctets, OutputOctets)
   SELECT UserName, '" . $Date_Small_Start . "', COUNT(RadAcctId), SUM(AcctSessionTime), MAX(AcctSessionTime), MIN(AcctSessionTime), SUM(AcctInputOctets), SUM(AcctOutputOctets)
   FROM RadiusAccounting
   WHERE AcctStopTime >= '" . $Date_Start . "' AND AcctStopTime < '" . $Date_End . "' AND UserName LIKE '%@%'
   GROUP BY UserName
   ```
3.  Удаление данных учета из таблиц Radius Accounting, которые мы только что скопировали в нашу собственную обобщенную таблицу Accounting Data.
   ```mysql
   DELETE FROM RadiusAccounting
   WHERE AcctStopTime >= '" . $Date_Start . "' AND AcctStopTime < '" . $Date_End . "' AND UserName LIKE '%@%'
   ```

В конце месяца я обычно выполняю запрос к моей ежедневной таблице учета и создаю ежемесячные итоги для моих пользователей в ежемесячной таблице учета. В конце дня я могу хранить 100 лет (если захочу) данных учета на основе ежемесячного использования с нулевым влиянием на сервер Radius… В конце месяца мы выполняем, среди прочего: перемещение обобщенных (мы теперь переходим с ежедневных на ежемесячные) данных учета из наших собственных таблиц учета в ежемесячные таблицы.
```mysql
INSERT INTO RadiusAcctMonthlyTotals (UserName, AcctDate, ConnNum, ConnTotDuration, ConnMaxDuration, ConnMinDuration, InputOctets, OutputOctets)
SELECT UserName, '" . $Date_Start . "', SUM(ConnNum), SUM(ConnTotDuration), MAX(ConnMaxDuration), MIN(ConnMinDuration), SUM(InputOctets), SUM(OutputOctets)
FROM RadiusAcctTotals
WHERE AcctDate >= '" . $Date_Start . "' AND AcctDate <= '" . $Date_End . "'
GROUP BY UserName
```
Удаление нашей ежедневной статистики из статистики, которые у нас есть в нашей ежемесячной таблице.
```mysql
DELETE FROM RadiusAcctTotals
WHERE AcctDate >= '" . $Date_Start . "' AND AcctDate <= '" . $Date_End . "'
```
Конечно, ты можешь создать свою собственную систему по своему усмотрению, и тебе не удастся просто скопировать и вставить мою, но ты поймешь суть. Данные нужно обрабатывать, нельзя просто вываливать их в базу данных и ожидать, что они будут работать вечно. Базовая идея заключается в том, чтобы иметь как можно меньше записей в таблицах учета, используемых Radius, но то, как ты этого достигнешь, очевидно, можно сделать множеством разных способов — некоторые из которых могут тебе подойти, некоторые — нет. — C

Рад, что смог помочь. Ещё один момент, чтобы прояснить ваш первоначальный вопрос (жалобу?) по поводу SessionID… SessionID генерируется NAS, но NAS требуется иметь уникальный Session ID только для каждого активного подключённого сеанса. Как только пользователь отключается и подключается другой, NAS имеет полное право присвоить тот же SessionID другому пользователю. Когда два пользователя подключены одновременно и имеют один и тот же SessionID – ТОГДА NAS точно не прав, и производителям нужно бы пристрелить и выставить на всеобщее обозрение (Это, разумеется, не относится к MPPP – которая в любом случае не поддерживается MT, но которая, очевидно, будет иметь один и тот же SessionID). Чтобы обойти это, FreeRadius разработал модуль UniqueID для генерации уникального хеша на основе значений различных атрибутов. Это тоже не гарантирует уникальность, но вероятность получения дубликата намного ниже. Если вы действительно умны и объедините это с модулем rlm_exec, вы можете сгенерировать хеш на основе /dev/random или /bin/date +%s, что гарантированно всегда будет уникальным (я даже видел, как люди используют SELECT UUID() в MySQL). В некоторых более крупных установках приходилось использовать что-то подобное.

Теперь у меня есть ещё одна тема, которую нужно обязательно внести в WIKI, когда у меня появится время... – C