Ошибки в верификаторе

[myelementisearth]

Доброе время суток, с УТМкой столкнулся не так давно, поэтому вопрос может показаться глупым, но вот в чем проблема, в верификаторе как я понимаю записываются ошибки которые происходят в системе, есть записи которые явно указывают на какие то неверные сервисные связки, при просмотре в админке пользователя в услугах увидел его старые привязки(абонентку и передачу трафика) с удалением вроде как все исчезает но буквально через пару дней увидел снова у этого же пользователя те же привязки, подтолкните на мысль, в чем может быть проблема и как искоренить

[WebTelecom]

остановить ядро и выполнить лог верификатора в базу.

[myelementisearth]

Понимаю, что проще всего сделать именно так, но хотелось бы разобраться, в связи с чем это произошло и как бороться

[dk]

1. Опасные правки (типа сервисных связок) часто закомментированы, и не исправляются при запуске верификатора без предварительных правок. Точно удаляется?

2. Урфаклиентом пользуетесь? Я им рушил тестовую базу во время изучения, причём видно это стало не сразу.

[marvin]

А никто не задавался целью написания собственного верификатора?

[WebTelecom]

по моему для этого нужно чётко понимать логику билинга, что в нашем случае проблематично ))

[myelementisearth]

1. Опасные правки (типа сервисных связок) часто закомментированы, и не исправляются при запуске верификатора без предварительных правок. Точно удаляется?

2. Урфаклиентом пользуетесь? Я им рушил тестовую базу во время изучения, причём видно это стало не сразу.

1. Удаляются, в моем случае не видел их пару дней, потом снова появились, а после накатывания верификатора возникают моментально как запускаю ядро
2. Пользуемся, но опять же, пытаюсь разобраться в работе УТМ, одно могу сказать, что бинарники есть, подключены библиотеки и скрипты от урфы

[myelementisearth]

Ошибки же следующего вида:

-- 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';

[dk]

Запросы экранированы --, значит, автоматически всё же не запускаются. Кроме того, эти запросы породят новые несвязанные данные, и после нескольких перезапусков/верификаций связки информация по ошибочным потеряется полностью.

Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.

[myelementisearth]

Запросы экранированы --, значит, автоматически всё же не запускаются. Кроме того, эти запросы породят новые несвязанные данные, и после нескольких перезапусков/верификаций связки информация по ошибочным потеряется полностью.

Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.

То есть предлагаете остановить ядро запустить верификатор запустить ядро проделать эту процедуру несколько раз ? а каким образом можно было как то в ручную в базе накосячить ?

[gtk]

Запросы экранированы --, значит, автоматически всё же не запускаются. Кроме того, эти запросы породят новые несвязанные данные, и после нескольких перезапусков/верификаций связки информация по ошибочным потеряется полностью.

Вообще, всё это сильно смахивает на ручное вмешательство в базу, так что не помешает пробежаться глазами по верификатору не для запуска исправления, а просто чтоб понять масштаб бедствий.

То есть предлагаете остановить ядро запустить верификатор запустить ядро проделать эту процедуру несколько раз ? а каким образом можно было как то в ручную в базе накосячить ?

Могу ошибаться, но накосячить можно когда удаляешь тариф. Или сразу пользователя. Когда надо, сначала удалить фиктивные услуги входящие в тарифный план. А потом уже тарифный план, и потом уже пользователя. Как-то, так.

[dk]

То есть предлагаете остановить ядро запустить верификатор запустить ядро проделать эту процедуру несколько раз ? а каким образом можно было как то в ручную в базе накосячить ?

Для начала предлагаю посмотреть, как в связки попала удалённая услуга (такого через урфу вроде как не получалось). Такие вещи исправляются только вручную, верификатор не поможет. Остальное -- можно и так; раскомментировать и прогонять верификатор, пока что-то останется. Удалится много всего, будьте готовы. Фактически, всё эти связки заново заносить придётся. Или же -- погрузиться в базу, найти правильные/неправильные данные и исправить.
Вручную накосячить -- легко (любой запрос на обновление/удаление по кэшируемым данным), через урфу тоже много способов.