> 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. _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
