We have two SQL 2008R2 boxes - each in a geographically separate data center - that stay sync'd using peer to peer replication (with a pair of smaller boxes acting as replication providers). This replication has been running like a champ for more than 3 years with no major issues. Recently we brought up a 2016 (with its own rep provider) box in a third data center with the ultimate goal that one of the 2008R2 data centers will go away. 2008R2-1 is still peer to peer with only 2008R2-2. As I understand it, 2008R2-2 has one peer-to-peer topology setup with -1 and another topology setup with 2016-1.
Now for the weird part. One table had normal user type updates occur between 13:52 and 13:55 on 9July2019. Then more updates happened on these same records. These changes originate on the 2008R2-1 box. Any changes to this table fire an audit trigger that records the original data, changed data, user, time, etc. Sometime between 14:40 and 14:50 on 11July2019 some data items reverted to the 9July changes. An example of what the audit may look like:
2019-07-09 13:55 DueDate 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 DueDate changed from 2019-07-11T12:00 to 2019-07-13T17:00 (Note the changed from data is the data from 7/9 and not the last data from 7/10)
No audit record of the data being changed back, just an audit record of the data being fixed. We can't think of anything other than replication that would skip the audit trigger. We also can't think of how / why replication would "hang onto" changes for two days and then apply them back down to the originating server. Any ideas on how this could possibly happen would be greatly helpful