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. 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=replicacontains all it's RUV's in it. When you do say:ldapsearch -b cn=config '(cn=replica)', that's a subtree search for allthe "cn=replica" under cn=config tree, so we'll show all the replicadetails 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
rg
-- Sincerely,William BrownSoftware EngineerRed Hat, Australia/Brisbane_______________________________________________389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxxTo unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
|
