dual master replication problem
807573Jul 23 2002 — edited Jul 24 2002We are using iplanet5.0 patch1.
Lately we have been encountering several problems with dual masters setup. If you can shed some light on these issues. That will be great.
There are three Solaris 8 boxes: A, B, C each having a LDAP server running.
A is configured to be a Master.
B is configured to be the second master. B is initialized by A.
C is configured to be a Readonly replica. C is intialized by B.
Problem 1:
If server B is down, then no changes can't be made to C.
I am just wondering why don't C refer the update to Master B?
The following configuration is taken from C.
cn="o=innovance.com",cn=mapping tree,cn=config
objectClass=top
objectClass=extensibleObject
objectClass=nsMappingTree
cn="o=innovance.com"
cn=o=innovance.com
nsslapd-state=referral on update
nsslapd-backend=userRoot
nsslapd-referral=ldap://B's IP address:389
nsslapd-referral=ldap://A's IP address:389
cn=replica,cn="o=innovance.com",cn=mapping tree,cn=config
objectClass=nsDS5Replica
objectClass=top
nsDS5ReplicaRoot=o=innovance.com
nsDS5ReplicaType=2
nsDS5Flags=0
nsDS5ReplicaId=255
nsds5ReplicaPurgeDelay=0
nsDS5ReplicaBindDN=cn=Replication Manager,cn=config
nsDS5ReplicaReferral=ldap://B's IP address:389
nsDS5ReplicaReferral=ldap://A's IP address:389
cn=replica
nsState=NOT ASCII
nsDS5ReplicaName=dd3ab404-1dd111b2-8054d64b-fd41a3ba
nsds5ReplicaChangeCount=0
Problem 2:
If both masters are up running, then creation via Slave C will result in two similar entries as following:
uid=testrole02,ou=roles,dc=security,o=innovance.com
uid=testrole02
roleDescription=test
objectClass=top
objectClass=InnovanceRole
nsuniqueid=55476801-1dd211b2-80ccd64b-fd41a3ba+uid=testrole02,ou=roles,dc=security,o=innovance.com
uid=testrole02
roleDescription=test
objectClass=top
objectClass=InnovanceRole
From the iplanet 5.0 deployment guide and release notes, it says as long as the referential integrity plugin is turned on on both masters, write conflicts will be resloved between them. However this does not seem the case. The access log from slapd does indicate that C (the slave) referred the write operations to both of the masters.
It begs another question: modifications seem working fine though deletion will cause problem since it tries to delete the same entry twice.
Regards,
Leo Sun