We have two SQL 2008R2 tables, each in a geographically separate data center, which are kept synchronized by peer-to-peer replication (with a couple of smaller tables that act as replication providers). This replication has been running like a champion for more than 3 years without major problems. Recently, we opened a 2016 chart (with its own representative provider) in a third data center with the ultimate goal of one of the 2008R2 data centers disappearing. 2008R2-1 remains peer to peer with only 2008R2-2. As I understand it, 2008R2-2 has a peer-to-peer topology configuration with -1 and another topology configuration with 2016-1.
Now for the weird part. One table had normal user type updates between 13:52 and 13:55 on July 9, 2019. Then more updates occurred in these same records. Any change in this table activates an audit trigger that records the original data, the modified data, the user, the time, etc. Sometime between 2:40 pm and 2:50 pm on July 11, 2011, some data items were reverted to the changes of July 9. An example of how auditing can be:
2019-07-09 13:55 The expiration date changed from 2019-07-11T12: 00 to 2019-07-11T17: 00
2019-07-09 15:30 DueDate changed from 2019-07-11T17: 00 to 2019-07-13T17: 00
2019-07-10 10:30 DueDate changed from 2019-07-13T17: 00 to 2019-07-15T17: 00
2019-07-10 14:30 DueDate changed from 2019-07-15T17: 00 to 2019-07-16T17: 00
2019-07-11 14:51 The expiration date changed from 2019-07-11T12: 00 to 2019-07-13T17: 00
There is no audit trail of the data that is being changed, just an audit trail of the data that is being repaired. Any ideas on how this could happen would be of great help