Ошибки в верификаторе
-
- Сообщения: 8
- Зарегистрирован: Чт янв 12, 2012 08:33
Ошибки в верификаторе
Доброе время суток, с УТМкой столкнулся не так давно, поэтому вопрос может показаться глупым, но вот в чем проблема, в верификаторе как я понимаю записываются ошибки которые происходят в системе, есть записи которые явно указывают на какие то неверные сервисные связки, при просмотре в админке пользователя в услугах увидел его старые привязки(абонентку и передачу трафика) с удалением вроде как все исчезает но буквально через пару дней увидел снова у этого же пользователя те же привязки, подтолкните на мысль, в чем может быть проблема и как искоренить
-
- Сообщения: 29
- Зарегистрирован: Пн янв 02, 2012 13:47
-
- Сообщения: 8
- Зарегистрирован: Чт янв 12, 2012 08:33
Ошибки в верификаторе
Понимаю, что проще всего сделать именно так, но хотелось бы разобраться, в связи с чем это произошло и как бороться
online verificator
А никто не задавался целью написания собственного верификатора?
-
- Сообщения: 29
- Зарегистрирован: Пн янв 02, 2012 13:47
-
- Сообщения: 8
- Зарегистрирован: Чт янв 12, 2012 08:33
dk писал(а):1. Опасные правки (типа сервисных связок) часто закомментированы, и не исправляются при запуске верификатора без предварительных правок. Точно удаляется?
2. Урфаклиентом пользуетесь? Я им рушил тестовую базу во время изучения, причём видно это стало не сразу.
1. Удаляются, в моем случае не видел их пару дней, потом снова появились, а после накатывания верификатора возникают моментально как запускаю ядро
2. Пользуемся, но опять же, пытаюсь разобраться в работе УТМ, одно могу сказать, что бинарники есть, подключены библиотеки и скрипты от урфы
-
- Сообщения: 8
- Зарегистрирован: Чт янв 12, 2012 08:33
Ошибки же следующего вида:
-- ERROR service link 12306 refer to service 298 which not exist
-- SQL DESC no sql, delete slink or create service
-- ERROR unexpected row in periodic_service_links with id 8562
-- SQL DESC delete row (NOT RECOMMENDED)
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='8562';
-- ERROR broken ip traffic link 7608, ip group 4424 not exist
-- SQL DESC delete slink (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='7608';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='7608';
-- UPDATE iptraffic_service_links SET is_deleted=1 WHERE id='7608';
-- ERROR link 13473, account tariff link id 7403, not equal discount period ids
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='13473';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='13473';
-- UPDATE iptraffic_service_links SET is_deleted=1 WHERE id='13473';
-- ERROR service link 12306 refer to service 298 which not exist
-- SQL DESC no sql, delete slink or create service
-- ERROR unexpected row in periodic_service_links with id 8562
-- SQL DESC delete row (NOT RECOMMENDED)
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='8562';
-- ERROR broken ip traffic link 7608, ip group 4424 not exist
-- SQL DESC delete slink (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='7608';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='7608';
-- UPDATE iptraffic_service_links SET is_deleted=1 WHERE id='7608';
-- ERROR link 13473, account tariff link id 7403, not equal discount period ids
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='13473';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='13473';
-- UPDATE iptraffic_service_links SET is_deleted=1 WHERE id='13473';
Запросы экранированы --, значит, автоматически всё же не запускаются. Кроме того, эти запросы породят новые несвязанные данные, и после нескольких перезапусков/верификаций связки информация по ошибочным потеряется полностью.
Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.
Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.
-
- Сообщения: 8
- Зарегистрирован: Чт янв 12, 2012 08:33
То есть предлагаете остановить ядро запустить верификатор запустить ядро проделать эту процедуру несколько раз ? а каким образом можно было как то в ручную в базе накосячить ?dk писал(а):Запросы экранированы --, значит, автоматически всё же не запускаются. Кроме того, эти запросы породят новые несвязанные данные, и после нескольких перезапусков/верификаций связки информация по ошибочным потеряется полностью.
Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.
myelementisearth писал(а):То есть предлагаете остановить ядро запустить верификатор запустить ядро проделать эту процедуру несколько раз ? а каким образом можно было как то в ручную в базе накосячить ?dk писал(а):Запросы экранированы --, значит, автоматически всё же не запускаются. Кроме того, эти запросы породят новые несвязанные данные, и после нескольких перезапусков/верификаций связки информация по ошибочным потеряется полностью.
Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.
Могу ошибаться, но накосячить можно когда удаляешь тариф. Или сразу пользователя. Когда надо, сначала удалить фиктивные услуги входящие в тарифный план. А потом уже тарифный план, и потом уже пользователя. Как-то, так.
Для начала предлагаю посмотреть, как в связки попала удалённая услуга (такого через урфу вроде как не получалось). Такие вещи исправляются только вручную, верификатор не поможет. Остальное -- можно и так; раскомментировать и прогонять верификатор, пока что-то останется. Удалится много всего, будьте готовы. Фактически, всё эти связки заново заносить придётся. Или же -- погрузиться в базу, найти правильные/неправильные данные и исправить.myelementisearth писал(а):То есть предлагаете остановить ядро запустить верификатор запустить ядро проделать эту процедуру несколько раз ? а каким образом можно было как то в ручную в базе накосячить ?
Вручную накосячить -- легко (любой запрос на обновление/удаление по кэшируемым данным), через урфу тоже много способов.