BiTel

Доброго времени суток.

Внедряю биллинг, испытываю разные сценарии работы под свои нужды и наткнулся на такую особенность работы системы:
1. Делаю любой платеж для клиента.
2. Удаляю платеж.
3. Штатно перезагружаю сервер со всеми необходимыми server_stop.sh, service mysqld stop и тому подобное.
4. После запуска системы тому же клиенту делаю новый платеж.
5. Удаляю его и получаю ошибку "ru.bitel.bgbilling.common.BGException: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '4' for key 'PRIMARY'"

Проверяю таблицы contract_payment & contract_payment_deleted.
Вижу в contract_payment_deleted платеж, удаленный в пункте 2. У него ID=4
В contract_payment вижу платеж, созданный в пункте 4, у него тоже ID=4.
Естественно - конфликт при удалении.

Очищаю contract_payment_deleted. Убираю последний платеж из contract_payment.
Повторяю сценарий - аналогичная картина.

Снова очистка.
Пробую сценатрий не с 1 платежем, а с несколькими. Несколько завел, потом все удалил.
Та же катрина - конфликт.

Снова очистка.
Повторяю без перезагрузки сервера - все работает как нужно.

Поскольку поле ID автоинкрементное, то виноват скорее всего mysql, который забывает в момент перезагрузки что там были записи с большим ID.
Но может ID платежа в contract_payment нужно дополнительно контролировать?
Возможно возникновение подобных ошибок и в других подсистемах при похожем сценарии.

Да, забыл совсем.
Клиент: вер. 7.0.867 / 23.01.2017 13:35:02
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_112
Сервер: вер. 7.0.1182 / 27.01.2017 17:01:29
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_40
bill: вер. 7.0.111 / 09.12.2016 13:27:55
mariadb-server-5.5.47-1.el7_2.x86_64

это известная и документированная фича мускуля и иннодб - при старте он пересчитывает значение текущего автоинкремента

_________________
I'm clever. I've got a computer.

Надо поменять тип индекса у таблицы contract_payment_deleted.
Исправим...