Двойные списания при смене тарифа 5.2.1-005

[Kayfolom]

Происходят странные вещи. Есть 2 группы тарифов - первая заведена до перехода на 5.2.1-005 (было 004), вторая уже на 5.2.1-005.
На всех тарифа стоимость снимается в начале расчетного периода. РП уникальны для каждого акаунта.
При смене тарифа следующего расчетного периода снимается стоимость нового тарифа (как и положено) и так же снимается стоимость старого тарифа.
При этом как я понял не отвязывается старый тариф, но в большинстве случаев в админке его не видно, а иногда видно только в услугах.
Рестарт ядра рождает верификатор.лог который это все лечит, но деньги то уже сняты, приходится ручками нескольким десяткам пользователей в день вносить компенсации, ну и ядро ребутить как минимум раз в сутки. О наездах со стороны пользователей вообще промолчу.
Подскажите куда комапь, где лечить и что вообще делать?

ЗЫ. В дебаглоге ерроров нет. Никаких жутко пиковых нагрузок на сервак нет (2 гига оперативы, больше 60% не отжирает), процессор тоже не нагружен (пиков под 100% нет, средняя 15%).

[Chris]

Тип списания может разный? типа в начале РСП и в конце РСП

[Magnum72]

ЗЫ. В дебаглоге ерроров нет. Никаких жутко пиковых нагрузок на сервак нет (2 гига оперативы, больше 60% не отжирает), процессор тоже не нагружен (пиков под 100% нет, средняя 15%).

поставь мускул на полное логирование, чет мне кажется что у тебя какие то апдейты мино кассы идут...

[Kayfolom]

Тип списания может разный? типа в начале РСП и в конце РСП

Тип списаний одинаковый. Тарифные планы вообще близнецы братья, отличаются только суммой и размером предоплаченного трафика.

[Kayfolom]

ЗЫ. В дебаглоге ерроров нет. Никаких жутко пиковых нагрузок на сервак нет (2 гига оперативы, больше 60% не отжирает), процессор тоже не нагружен (пиков под 100% нет, средняя 15%).

поставь мускул на полное логирование, чет мне кажется что у тебя какие то апдейты мино кассы идут...

Ок. Спробую. Тем более что битье в бубен повернуло ветер в сторону мускуля - при очередном глюке (примерзании админки и винтреевских утилит, причем логи утм продолжали писаться в стиле все ОК, я работаю нормально) ребут мускуля помог вернуть биллинг к жизни. Буду вычислять в чем дело - или MySQL (CentOS, установленный по дефолту мускуль с тремя строчками конфига), или билинг чтото ему посылает в хавальник жестокое.

[Kayfolom]

Все что нашел в дебаге мускуля - ролбак транзакции, остальное вроде все ок.

Код: Выделить всё

080413  0:00:00
BEGIN
SELECT id FROM blocks_info WHERE what_blocked='3' AND service_id='1295' AND block_type='0' AND start_date<
='1208030400' AND expire_date>='1208030400' AND is_deleted='0'
SELECT id FROM blocks_info WHERE what_blocked='3' AND service_id='1295' AND block_type='1' AND start_date<
='1208030400' AND expire_date>='1208030400' AND is_deleted='0'
SELECT id FROM blocks_info WHERE what_blocked='3' AND service_id='1295' AND block_type='2' AND start_date<
='1208030400' AND expire_date>='1208030400' AND is_deleted='0'
UPDATE blocks_info SET is_deleted=1,expire_date='1208030400' WHERE what_blocked=3 AND slink_id=1295
UPDATE dtagg_periodic SET discounted='0.000000',discounted_without_tax='0.000000' WHERE id='536'
UPDATE service_links SET is_deleted=1 WHERE id='1295'
UPDATE periodic_service_links SET is_deleted=1 WHERE id='1295'
ROLLBACK

В дебаге биллинга при этом:

Код: Выделить всё

 ERROR : Apr 13 00:00:00 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 25
 ERROR : Apr 13 00:00:00 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=27, links_count 25
*CRIT  : Apr 13 00:00:33 UTM5 DBA: db verificator find critical error(s), see /netup/utm5/log/verificator.log for details
 ERROR : Apr 13 00:00:33 StreamManager: bind failed: Address already in use
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 26
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 26
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=52, links_count 16
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=52, links_count 16
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=76, links_count 88
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=76, links_count 88
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=77, links_count 30
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=77, links_count 30
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=81, links_count 157
 ERROR : Apr 13 00:00:33 DBAGlukError: DBAccess::__delete_service, service_id=81, links_count 157
 ERROR : Apr 13 00:00:34 ModFWMan: No info for FW 2 found
 ERROR : Apr 13 00:00:34 ModFWMan: No info for FW 2 found
 ERROR : Apr 13 00:05:00 DBCtx: MySQL query failed:
 ERROR : Apr 13 00:05:00 DBASQLError: MySQL query failed:
 ERROR : Apr 13 00:05:00 DBCtx: Exception while doing SQL insert/update !
 ERROR : Apr 13 00:05:01 DBAGlukError: DBAccess::__delete_service, service_id=81, links_count 156
 ERROR : Apr 13 00:05:01 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=81, links_count 156
 ERROR : Apr 13 01:00:00 DBAGlukError: DBAccess::__delete_service, service_id=77, links_count 29
 ERROR : Apr 13 01:00:00 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=77, links_count 29
 ERROR : Apr 13 01:07:07 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 25
 ERROR : Apr 13 01:07:07 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=27, links_count 25
 ERROR : Apr 13 01:07:07 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 24
 ERROR : Apr 13 01:07:07 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=27, links_count 24
 ERROR : Apr 13 01:07:07 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 23
 ERROR : Apr 13 01:07:07 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=27, links_count 23
 ERROR : Apr 13 01:07:07 DBAGlukError: DBAccess::__delete_service, service_id=27, links_count 22
 ERROR : Apr 13 01:07:07 DBAGlukError: [close multi delete slink internal] DBAccess::__delete_service, service_id=27, links_count 22
*CRIT  : Apr 13 01:07:38 UTM5 DBA: db verificator find critical error(s), see /netup/utm5/log/verificator.log for details
 ERROR : Apr 13 01:07:38 StreamManager: bind failed: Address already in use
 ERROR : Apr 13 01:07:39 ModFWMan: No info for FW 2 found
 ERROR : Apr 13 01:07:39 ModFWMan: No info for FW 2 found
 ERROR : Apr 13 01:07:39 ModFWMan: No info for FW 2 found
 ERROR : Apr 13 01:07:39 ModFWMan: No info for FW 2 found

Рождается верификатор лог (каждый день):

Код: Выделить всё

-- Verificator
-- You have to backup UTM5 database!
-- Affected tables list at the end of file

-- ERROR link 502, tariff_link_id 238 not exist
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='502';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='502';

-- ERROR link 502, wrong tariff id
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='502';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='502';

-- ERROR link 502, account tariff link id 238, not equal discount period ids
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='502';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='502';

-- ERROR link 514, tariff_link_id 250 not exist
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='514';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='514';

-- ERROR link 514, wrong tariff id
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='514';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='514';

-- ERROR link 514, account tariff link id 250, not equal discount period ids
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='514';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='514';

Самое обидное что биллинг обрабатывает закрытие всего 20-30 разчетных периодов в день (уникальные для каждого пользователя, размазаны равномерно по всему месяцу), т.е. нагрузки фактически никакой. Но просыпаться кадный день в час ночи и править ручками, запуливать верификаторлог, ребутить биллинг. Коллеги сидят на трафик-инспекторе и ланбиллинге и откровенно на до мной глумятся, предлагая забить на нетап и перейти на калькурятор - точнее и надежнее.

[mikkey finn]

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

[Kayfolom]

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

Нерекомендованные раскоменчиваю и запускаю. Уже на протяжении полутора месяцев. Кждый день. Глюки продолжаются. Такое ощущение что биллинг разучился удалять старые привязки. Появилось это после перехода ч 004 на 005. Как и обещали разработчики пропали глюки с предоплаченным трафиком, зато появилось несколько новых, еще более гнусных. Жду с нетерпением 006 - в ней видимоо вообще придется нанять бригаду расчетчиков с калькуляторами чтоб хоть как то держать билинг на плаву.

[Magnum72]

Слушай а у тебя количество списайни не указано в расчетном периоде ? просто у меня после того как я указал 7 в неделю теперь каждую ночь в 0:20 загрузка процов 100%, из-за того что он теперь списывает со всех пользователей абонентку в одно и тоже время.

[Kayfolom]

Слушай а у тебя количество списайни не указано в расчетном периоде ? просто у меня после того как я указал 7 в неделю теперь каждую ночь в 0:20 загрузка процов 100%, из-за того что он теперь списывает со всех пользователей абонентку в одно и тоже время.

Все расчетные периоды по дефолту, длинной в месяц. По munin никаких пиков ни в проце, ни в мускуле, машинка загружена на 5-10%.
Странное заметил еще что пропал из админки расчетный период с ID 1 (он никогда не использовался). Причем в базе он есть. Видимо в 005 его спрятали от глаз подальше?
Еще одна странность:
В выше приведенном логе mysql в 00:00 первым делом запускаются транзакции (080413 0:00:00 BEGIN)(хотя в конфигах db_transaction_enable - по умолчанию unset) часть из которых помирает не выполнившись (ROLLBACK), биллинг этого видимо не замечает и продолжает лопатить. Видимо из за этих проигноренных откатов все проблемы.

[Instruktor]

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

Нерекомендованные раскоменчиваю и запускаю. Уже на протяжении полутора месяцев. Кждый день. Глюки продолжаются. Такое ощущение что биллинг разучился удалять старые привязки. Появилось это после перехода ч 004 на 005. Как и обещали разработчики пропали глюки с предоплаченным трафиком, зато появилось несколько новых, еще более гнусных. Жду с нетерпением 006 - в ней видимоо вообще придется нанять бригаду расчетчиков с калькуляторами чтоб хоть как то держать билинг на плаву.

Проблема как-нибудь разрешился?
У меня наблюдается то же самое. Версия сборка 006

[adeep]

есть такая же фигня на -005. проявилась пару месяцев назад, до сих пор происходит.
Не у всех пользователей, но при смене тарифа остается старая привязка с таким же ипом и старыми услугами. Если удалять, то после перезапуска биллинга появляется заново. Пропадает если в новом тарифе поменять клиенту ип адрес. Но похоже что тогда начинает глючить еще глубже - у некоторых пользователей не показывает услуги вообще, хотя все работает.

[Kayfolom]

Вот решение
viewtopic.php?t=5722&start=0&postdays=0 ... highlight=

[Slad]

Если решение - перевести в myisam, то не поможет.

[Kayfolom]

Мне помогло.