дублирования трафика после переноса базы на другую машину
дублирования трафика после переноса базы на другую машину
Стоит MySQL 5.0.20, перенесли базу, остановив MySQL на первой машине, скопировали бинарные файлы UTM4 на другую машину. После этого обнаружили, что трафик дублируется, детальный отчёт по трафику клиентов выводит повторяющиеся дважды строки трафика.
Под "бинарными файлами UTM4" я имел в виду бинарные файлы sql-базы, конечно же.Gemorroy писал(а):А зачем бинарники пересли? Переустановили бы. Тут надо руководствоваться принципом : лучшее - враг хорошего.
А вообще проблема решилась, похоже, заведением sql-сервера в другую подсеть, поскольку в основной обнаружилась странная проблема - пропадания сетевых пакетов...
-
Ilya Evseev
- Сообщения: 12
- Зарегистрирован: Пн фев 20, 2006 19:11
- Откуда: SPb, Russia~
- Контактная информация:
Ни хрена эта проблема у нас с Dyr'ом не решилась, трафик в детальных отчётах как дупился, так и продолжает дупиться, троиться и четвериться. Сответственно утекают и пользовательские денежки.
Дупы начались после замены ящика, на котором крутится SQL-сервер. UTM и серверы доступа крутятся на отдельных ящиках.
У нас работает связка ipfw + divert sockets + ndsad 1.33 + netup_netflow. ndsad не дупит - смотрели через flowtools.
netup_netflow тоже в порядке - смотрели через "select id, INET_NTOA(srcaddr), srcport, INET_NTOA(dstaddr), dstport, FROM_UNIXTIME(First), FROM_UNIXTIME(Last) from UTM4.traffic_netflow limit 40;" в разные моменты времени.
Остаются либо tsave, либо mysql (версия 5.0.20 из фряхиных портов).
Самый главный вопрос: сталкивался ли до нас с чем-нибудь подобным кто-нибудь ещё?
Вопрос №2: если виноваты повреждения в структуре базы MySQL, то можно ли прочекать базу UTM, не останавливая работы?
Как минимум Радиус должен продолжать работать.
Вопрос №3: допустим, виноват tsave и мы хотим сразу после него запускать подчищалку. Какие таблицы она должна чистить? Только traffic или все traffic_* ?
То есть: traffic_* формируются на основании уже подчищенной traffic раз в день/час/месяц/...? Или они все формируются непосредственно из traffic_netflow/traffic_tmp?
Вопрос №4: допустим, виноват tsave. Можно ли создать на таблицах уникальные ключи, которые помешают записывать дупы? Если да, то в каких таблицах, и из каких полей?
Вопрос №5: что ещё можно сделать?!?!?!!!!
Дупы начались после замены ящика, на котором крутится SQL-сервер. UTM и серверы доступа крутятся на отдельных ящиках.
У нас работает связка ipfw + divert sockets + ndsad 1.33 + netup_netflow. ndsad не дупит - смотрели через flowtools.
netup_netflow тоже в порядке - смотрели через "select id, INET_NTOA(srcaddr), srcport, INET_NTOA(dstaddr), dstport, FROM_UNIXTIME(First), FROM_UNIXTIME(Last) from UTM4.traffic_netflow limit 40;" в разные моменты времени.
Остаются либо tsave, либо mysql (версия 5.0.20 из фряхиных портов).
Самый главный вопрос: сталкивался ли до нас с чем-нибудь подобным кто-нибудь ещё?
Вопрос №2: если виноваты повреждения в структуре базы MySQL, то можно ли прочекать базу UTM, не останавливая работы?
Как минимум Радиус должен продолжать работать.
Вопрос №3: допустим, виноват tsave и мы хотим сразу после него запускать подчищалку. Какие таблицы она должна чистить? Только traffic или все traffic_* ?
То есть: traffic_* формируются на основании уже подчищенной traffic раз в день/час/месяц/...? Или они все формируются непосредственно из traffic_netflow/traffic_tmp?
Вопрос №4: допустим, виноват tsave. Можно ли создать на таблицах уникальные ключи, которые помешают записывать дупы? Если да, то в каких таблицах, и из каких полей?
Вопрос №5: что ещё можно сделать?!?!?!!!!