BiTel

Настраиваю чистку файлов старых радиус-логов из data/radius.
Вижу в базе таблицы connection_log_entry_{mid}_yyyyMM.
Я так понимаю, это координаты радиус-логов по сессиям в этих файлах.
Вопрос: безопасно ли удалять таблицы connection_log_entry_{mid}_yyyyMM за те месяца, для которых логи уже удалены?
В плане, не будет ли эксепшена, когда биллинг запросит радиус-лог сессии из inet_session_log_{mid}_{YYYYMM}, если нет не только файлов, но и таблицы connection_log_entry_{mid}_yyyyMM за тот же месяц?

У нас часто используется метод, который проверяет существует ли таблица. И если существует - он кэширует это. Т.е. до перезапуска сервера он будет думать что таблица есть.

Хм, надо будет посмотреть, как можно этот кэш почистить

Сейчас нет такого метода.

А как это работает с модулем DBA?

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

TODO метод очистки кэша tableExists?

Кстати, в том же ServerUtils есть метод dropExistTable(...), который явно не работает с tableExists(...)

v 5.2, если что

up?

Снова настраиваю удаление старых таблиц.
Сделайте пожалуйста метод в ServerUtils, позволяющий удалить данные из кэша существующих таблиц.
Что-то вроде:



Или, если tableName==null, чистить весь кэш - может пригодиться.

Хотя о чём я, так просто не выйдет - нужно через нотификации через MQ во всех приложениях чистить.

Я добавил в TODO, но мне кажется, что это не критично.