> A CSN is generated with each externally applied modification, not for a > replicated operation This is very useful information; thank you. > The RUV is a vector of CSNs for all replicaids a specific replica has > seen So each replica has its own RUV which ideally should be the same across all replicas, but which may temporarily differ as replication occurs. And the RUV contains a list of all the replicas and the most recent CSN it knows about from that replica. I think part of my confusion is that the RUV for a replica seems to be hidden. I think I've discovered that it's in the cn=replica,cn=...,cn=mapping tree, cn=config as the "nsds50ruv" multivalue attribute, but I have to explicitly request that attribute. Neither "*" nor "+" returns it, nor does a search for "(nsds50ruv=*)", which makes it hard to find. Additionally confusing me was the fact that "nsds50ruv" attributes do show up in the replication agreement entries that are children of that entry, and they seem to contain cached values of the remote replicas RUVs at, I'm guessing, the last time they initiated a replication event. Ultimately, I think I mostly understand now. A change happens on a replica, it assigns a CSN to it and updates its RUV to indicate that that's now the newest CSN it has. Then a replication event occurs with its peers and those peers basically say "you have something newer; send me everything you originated after this last CSN from you that I know about". And then a replication event happens to their peers and they see that there's something new from that replica, etc. I think the biggest thing I don't understand now is how to associate changes with CSNs. It's supposed to be in the changelog, but the only changes I see in "cn=changelog" are for "idnsname" DNs, and there are definitely more changes going on than that. > Now assume that the updates 100x have been conflicting I'm not really concerned at the moment with conflicting updates. I get why that's a problem and I generally understand the "+nsuniqueid" conflict resolution method. My problem is occurring without conflicting updates. -- _______________________________________________ 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
