Thanks Willam. It does make sense now. I don't know how I could have misunderstood it :) So thank you again for clarifying it!
> On Nov 7, 2017, at 4:44 PM, William Brown <wibr...@redhat.com> wrote: > >> On Tue, 2017-11-07 at 13:33 -0600, Sergei Gerasenko wrote: >> Hi, >> >> I was going through RedHat’s documentation on naming conflicts. >> Here’s what it says at the beginning (https://access.redhat.com/docum >> entation/en- >> us/red_hat_directory_server/10/html/administration_guide/managing_rep >> lication-solving_common_replication_conflicts >> <https://access.redhat.com/documentation/en- >> us/red_hat_directory_server/10/html/administration_guide/managing_rep >> lication-solving_common_replication_conflicts>): >> >> 14.23.1. Solving Naming Conflicts >> When two entries are created with the same DN on different servers, >> the automatic conflict resolution procedure during replication >> renames the last entry created, including the entry's unique >> identifier in the DN. Every directory entry includes a unique >> identifier given by the operational attribute nsuniqueid. When a >> naming conflict occurs, this unique ID is appended to the non-unique >> DN. >> <> >> What I don’t understand is how conflicts can happen at all if the >> last one wins? > > The point is that if the last one wins, what do we do with the first? > We don't want to just delete it in case the order of operations was not > what the admin expected. So when you do: > > Master 1 Master 2 > > Time 0 ADD E > > Time 1 ADD E > > We are going to keep M1 E, and we'll conflict on M2 E - this becomes > the conflict entry. > >> Also, they are talking about solutions to the conflicts and >> specifically renaming the user that has nsuniqueid prepended. Does >> that assume that the conflicting user is actually another person? Or >> does it mean the conflicting record denotes the same user? If it’s >> the same user, shouldn’t the conflicting record just be removed? >> Really confused about the nature of the problem and the suggested >> solutions. >> Thanks! > > See above. It's about preserving the duplicate entry incase the > administrator wishes to revive them or see what happened. :) > > > Hope that helps, Ludwig might have more to say on this. > >> _______________________________________________ >> 389-users mailing list -- 389-users@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o >> rg > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
