The explanation below looks excellent to me
Things that I currently know I don't know include:
* When/where a new CSN is generated. If a piece of data is changed on a particular
replica, that must obviously create a new CSN. When that data is replicated, does the
accepting replica create its own CSN for that change or does it copy the initiating
replica's CSN? I think it's the former, but I'm not sure, because:
* How are CSNs compared? Since the CSN contains a replica ID, it seems like there's
the potential for one replica's updates to prevent others' updates from
propagating. Unless that isn't really used in the comparison. In which case,
what's it doing in there?
* How a replica knows what data to send based on CSN comparison.
I'm sure that there are things that I don't yet know that I don't know, but
that knowledge feels like it's gated partially by the answers to these questions.
A key element is that there is no synchronous
replication, an update is not sync immediately to all replicas.
To be clear, I'm not saying that sometimes it takes minutes or hours for the replicas
to become synchronized. I'm saying that occasionally some random data change never
synchronizes, even over weeks or months. For example, I have a user who changed his
password three weeks ago, and parts of that change are still missing from a few of my
replicas. All the changes that have happened since then (of which there are many) have
successfully replicated to all of my replicas.
One of the reasons that I'm running down this path is that the audit logs show that
this password change, which involves changes to many values within a single entry, was,
for some reason, apparently split into two separate modify operations, one of which is a
change to "krbExtraData" and the other of which contains changes to a bunch of
other attributes. All replicas show the former in the audit log, but a small number of
replicas don't show the latter at all. Since those changes happened at exactly the
same time, I'm looking into how replication uses timestamps and replica IDs to
determine what data needs to be replicated, and, while I feel like it's unlikely that
this is the problem, I also don't have enough data to disprove it.