Люди, у кого уже используется ipv6? Не возникало ли у вас проблем с отчетами? Запустил у себя тестовых камикадзе на предмет как пойдет. Технически все работает. Есть проблемы с биллингом.
Первое - не удается авторизироваться в альтернативном личном кабинете заходя с ipv6 адресов, и вот сейчас обнаружилась проблема с отчетами по трафику. Вместо ipv6 адресов, в отчетах отображается только последние четыре октета от ipv6 адреса. Проблема есть как и в админке, так и в вебморде
Неправильное отображение ipv6 в отчетах по трафику
-
Nik0n
- Сообщения: 77
- Зарегистрирован: Пн сен 14, 2009 13:53
- Откуда: Екатеринбург
- Контактная информация:
ИМХО И у тех кто честно их архивирует тоже будут проблемы - возникнет необходимость добавлять эти поля во ВСЕ архивные таблицы.serjk писал(а):Проблема нам известна, связана с необходимостью добавление нескольких новых колонок в огромные таблицы discount_transactions_iptraffic_all, что может поставить под угрозу обновление биллинга у клиентов, не архивирующих длинные таблицы.
Сам лично попал при обновлении с 5.2 до 5.3 на tel_session_log и _detail - админка не показывала отчеты телефонии, а наши юрики могут их смотреть по полгода
Ладно таблицы не такие огромные, но пришлось им делать myisamchk --unpack, а потом обратно myisampack.Что только люди ни делают, лишь бы не использовать нормальную СУБД (в которой, к слову, специально для IP всех версий имеется тип данных, обеспечивающий индексацию, поиск по диапазонам, шаблонам и по маске без каббалы преобразования uint64+uint64).
Где-то в районе 2009-2010 годов был серьезный апдейт структуры БД UTM с добавлением-удалением-изменением полей как раз в этих самых больших таблицах. Да, времени это заняло прилично, но изменение таблиц в 150-200 млн. записей принципиальных проблем не создало. Что такого произошло за пять лет, что четыре запроса на поле (3 ALTER TABLE + 1 UPDATE), стали неподъемной задачей?
Где-то в районе 2009-2010 годов был серьезный апдейт структуры БД UTM с добавлением-удалением-изменением полей как раз в этих самых больших таблицах. Да, времени это заняло прилично, но изменение таблиц в 150-200 млн. записей принципиальных проблем не создало. Что такого произошло за пять лет, что четыре запроса на поле (3 ALTER TABLE + 1 UPDATE), стали неподъемной задачей?
Это не проблема. Скрипт, генерирующий SQL для апдейта всех таблиц пишется за 10 минут с проверкой на стенде.ИМХО И у тех кто честно их архивирует тоже будут проблемы - возникнет необходимость добавлять эти поля во ВСЕ архивные таблицы.