Я реализую фоновый процесс для перемещения записей журнала событий из базы данных SQL в mongoDB.
Известно, что записи в журнале событий / журнале аудита изменяются только один раз в конце события.Процесс выглядит следующим образом:
1) создается запись в журнале событий, чтобы зафиксировать, что бизнес-процесс был инициирован
2) запущена новая транзакция для бизнес-процесса
3) создаются записи журнала аудита
4) попытки обновить запись в журнале событий с успешным статусом
5) транзакция завершается
6) в случае сбоя транзакции- обновляет запись в журнале событий как неудачную
Таким образом, теоретически фоновый процесс может безопасно прочитать все записи журнала, которые уже были помечены как неудачные / успешные, и, скорее всего, после определенного времени ожидания также может безопасно прочитатьзаписи, которые по неизвестной причине застряли в состоянии «Процесс был запущен».
Чтобы избежать каких-либо блокировок таблицы журнала событий, пока фоновый процесс читает записи журнала событий в пакетах, я хотел бы использовать расслабленную изоляциюуровень, но я не уверен, какой из них будет безопасно использовать на столе, который будет иметь много параллельных вставок иобновления происходят постоянно (хотя обновления только для записей, которые мой фоновый процесс будет игнорировать;поэтому меня не волнует грязное чтение).
В моем случае вполне допустимо пропустить записи, которые вставляются прямо сейчас (я получу их при следующем запуске фонового заданияв любом случае) но недопустимо получать дубликаты / отсутствующие записи среди старых записей, которые не обновляются прямо сейчас.
PS Вы можете спросить - почему бы не войти напрямую в mongoDB?Есть две причины: 1) в базе данных есть много триггеров и хранимых процедур, которые ведут журнал в таблицу SQL, и клиент не хочет переопределять все это;2) клиент хочет обеспечить атомарность журнала событий / контрольного журнала с транзакцией бизнес-процесса, и он боится, что при прямом ведении журнала на mongoDB могут быть случаи, когда по некоторым (наиболее вероятно - очень критическим) записям журнала событий причины пропадаютв то время как транзакция SQL прошла успешно, и данные были изменены.Нетрудно включить запись в mongoDB в одну атомарную единицу работы с транзакцией SQL.