У нас есть два блока SQL 2008R2 - каждый в географически отдельном центре обработки данных - которые синхронизируются с использованием одноранговой репликации (с двумя меньшими блоками, выступающими в качестве поставщиков репликации). Эта репликация работает как чемпион более 3 лет без каких-либо серьезных проблем. Недавно мы подняли коробку 2016 (со своим собственным поставщиком) в третьем центре обработки данных с конечной целью, чтобы один из центров обработки данных 2008R2 ушел из эксплуатации. 2008R2-1 по-прежнему является одноранговым, только с 2008R2-2. Насколько я понимаю, 2008R2-2 имеет одну настройку одноранговой топологии с -1 и другую настройку топологии с 2016-1.
Теперь самое странное. В одной таблице обновления типов обычных пользователей происходили между 13:52 и 13:55 9 июля 2019 года. Затем произошли новые обновления этих же записей. Любые изменения в этой таблице запускают триггер аудита, который записывает исходные данные, измененные данные, пользователя, время и т. Д. Где-то между 14:40 и 14:50 11 июля 2019 года некоторые элементы данных вернулись к изменениям 9 июля. Пример того, как может выглядеть аудит: 2019-07-09 13:55 DueDate изменен с 2019-07-11T12: 00 на 2019-07-11T17: 00 2019-07-09 15:30 DueDate изменен с 2019-07 -11T17: 00 на 2019-07-13T17: 00 2019-07-10 10:30 Срок выполнения изменен с 2019-07-13T17: 00 на 2019-07-15T17: 00 2019-07-10 14:30 Срок выполнения изменен с 2019 -07-15T17: 00 на 2019-07-16T17: 00 2019-07-11 14:51 Срок выполнения изменен с 2019-07-11T12: 00 на 2019-07-13T17: 00
Нет записи аудита данных, изменяемых обратно, только запись аудита исправляемых данных. Любые идеи о том, как это могло произойти, были бы очень полезны