Not quite. When we have this scenario:

    M1    M2

T0  Add E1

T1        Add E2
...

Thank you, William. 


Also, and this is more of a general LDAP question, in the same
article they talk about removing dangling RUVs. They do a search
for: 

dn:cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

But the ldapsearch command doesn’t specify the whole path. Instead,
it’s just -b cn=config cn=replica. How does the server find replica
under mapping tree if we only specified the base of cn=config?

I'm not sure I completely understand the question sorry. 

Sorry I wasn’t clear. Below is the excerpt from the article. Note they are saying “cn=replica” under “cn=config”, but the full DN is dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

That is, cn=replica is not _directly_ under cn=config. Doesn’t cn=…,cn=…,cn=… imply hierarchy? In other words, I’m confused how ldapsearch could find the replica entry if the base was specifying just cn=config and not cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

That’s why I think I might have some conceptual misunderstanding about LDAP in general.

Thanks again.


...
List the currently defined and valid replica IDs of all masters which are replicating databases by searching the replica configuration entries DN cn=replica under the cn=config suffix.

Note

Consumers and read-only nodes always have the replica ID set to 65535, and nsDS5ReplicaType: 3 signifies a master.
# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com m2.example.com -D "cn=Directory Manager" -W -b cn=config cn=replica nsDS5ReplicaId nsDS5ReplicaType
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaId: 1
nsDS5ReplicaType: 3

dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaId: 20
nsDS5ReplicaType: 3
...



We only have one cn=replica per mapping tree entry. IE a suffix
(dc=example,dc=com), can only have one cn=replica. And that cn=replica
contains all it's RUV's in it. 

When you do say:

ldapsearch -b cn=config '(cn=replica)', that's a subtree search for all
the "cn=replica" under cn=config tree, so we'll show all the replica
details for all mapping trees,

Does that help at all? 


Thank you again,
  Sergei

No problem. I think there is an easier way to simulate this.

Make sure you have MMR setup (IE agreement from M1 -> M2, and M2 ->
M1).

Then on both, there is an agreement object, something like:

cn=ExampleAgreement,cn=replica,cn=dc=example\,dc=com,cn=mapping
tree,cn=config

To that object on *BOTH* masters add:


nsds5ReplicaEnabled: off

This will pause all replication.


Now, add your "user1" to both M1 and M2. Try to make them have the
same
DN, but different attributes like:

uid=user,ou=People,....
...
description: m1

uid=user,ou=People,....
...
description: m2


Next, on both masters set:


nsds5ReplicaEnabled: on


This will trigger a replication update. You should have conflict
entries on your servers now :) 


Anyway, in reality, it's rare you'll ever see conflicts like this,
but
I'm glad you are researching this so thoroughly, 

_______________________________________________
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-leave@lists.fedoraproject.org