UTM5 build 14
mysql 3.23.58 таблицы MyISAM
все клиенты сидят на однос расчетном периоде с 1 по 1 число
в ночь с последнего числа месяца на первое число нового месяца все клиенты переходят на новый расчетный период.
После чего появляется в базе много ошибок - (1)многие клиенты незаблокированные отображаются как заблокированные, но в действительности работают нормально. (2)У уже заблокированных тем не менее снимается абонентская плата, хотя стоят галочки "Не списывать абонентскую плату в заблокированном состоянии" и плавное списание.
После перезапуска (1) клиенты блокируются, несмотря на положительный баланс, (2) клиенты начинают нормально работать.
В верификатор.лог всего три ошибки, хотя блокируется неверно после перезапуска биллинга намного больше.
-- Verificator
-- Backup db with mysqldump -uASDF -pASDF UTM5
-- Affected tables list at the end of file
-- ERROR account 829 not blocked, but where is entry with id 5369 in blocks_info
-- SQL DESC delete entry in blocks_info
UPDATE blocks_info SET is_deleted=1 WHERE what_blocked='2' AND account_id='829' AND start_date<='1134388329' A
-- ERROR account 641 not blocked, but where is entry with id 5454 in blocks_info
-- SQL DESC delete entry in blocks_info
UPDATE blocks_info SET is_deleted=1 WHERE what_blocked='2' AND account_id='641' AND start_date<='1134388329' A
-- ERROR account 1133 not blocked, but where is entry with id 5482 in blocks_info
-- SQL DESC delete entry in blocks_info
UPDATE blocks_info SET is_deleted=1 WHERE what_blocked='2' AND account_id='1133' AND start_date<='1134388329'
-- 3 errors
-- 0 warnings
-- affected tables: blocks_info
Как избежать этой проблемы?
Вероятно это происходит из большого количества операций mysql при переходе на новый расчетный период?
Ошибки в базе при переходе на новый расчетный период
возможно и из-за этого. Рекомендуется конечно обновиться до mysql 4.x и использовать таблицы InnoDB.
Для определения в чем проблема желательно проанализировать логи ядра при закрытии расчетного периода - их много, но в принципе они однотипные на всех абонентов т.е. достаточно определить места в логах где, что-то идет не по "накатанной" (например пошли реконнекты к базе данных и т.д.). Можно скинуть вырезки из логов сюда.
Для определения в чем проблема желательно проанализировать логи ядра при закрытии расчетного периода - их много, но в принципе они однотипные на всех абонентов т.е. достаточно определить места в логах где, что-то идет не по "накатанной" (например пошли реконнекты к базе данных и т.д.). Можно скинуть вырезки из логов сюда.