Yes, I agree with you. My basic question is that how come the same scenario is supported in the older version but not in latest OpenLDAP 2.4.44 with MDB backend. During this scenario, contextCSNs of both the MM1 and MM2 get updated correctly on MDB (OpenLDAP 2.4.44) and BDB (OpenLDAP 2.4.11) See below the contextCSN values of MM1 and MM2. ######################### MM1 on BDB (OpenLDAP 2.4.11) ######################### contextCSN: 20160718052917.405929Z#000000#000#000000 contextCSN: 20160718053109.639168Z#000000#001#000000 contextCSN: 20160718053249.495430Z#000000#002#000000 ######################### MM2 on BDB (OpenLDAP 2.4.11) ######################### contextCSN: 20160718052917.405929Z#000000#000#000000 contextCSN: 20160718053249.495430Z#000000#002#000000 contextCSN: 20160718053109.639168Z#000000#001#000000 ######################### MM1 on MDB (OpenLDAP 2.4.44) ######################### contextCSN: 20160717234101.093387Z#000000#000#000000 contextCSN: 20160717234320.498152Z#000000#001#000000 contextCSN: 20160717234453.544103Z#000000#002#000000 ######################### MM2 on MDB (OpenLDAP 2.4.44) ######################### contextCSN: 20160717234101.093387Z#000000#000#000000 contextCSN: 20160717234320.498152Z#000000#001#000000 contextCSN: 20160717234453.544103Z#000000#002#000000 >From the contextCSNs values on both backends I got that MM1 and MM2 are in sync. When I did slapcat on BDB, I found that LDIF entries with entryCSN equals to three contextCSN with i.e. server id #000, #001 and #002 are present in the LDIF files (attached files 'slapcatExportMM1_BDB.ldif' and 'slapcatExportMM2_BDB.ldif'). When I did slapcat on MDB, I found that LDIF entries with entryCSN equals to contextCSN with i.e. server id #000 and #002 are present in the LDIF file (exported file) but LDIF with entryCSN equals to contextCSN with server id #001 is not present in LDIF files (attached files 'slapcatExportMM1_MDB.ldif' and 'slapcatExportMM2_MDB.ldif'). Is it possible that contextCSN value is updated in the MDB but LDIF entry is not present in the DB corresponding to the same contextCSN? Thanks Gurjot Kaur -----Original Message----- From: Ulrich Windl [mailto:Ulrich.Windl@rz.uni-regensburg.de] Sent: Friday, July 15, 2016 4:56 PM To: Gurjot Kaur <gurjot.kaur@aricent.com>; openldap-technical@openldap.org Subject: Antw: replication issue with MDB in ldapadd >>> Gurjot Kaur <gurjot.kaur@aricent.com> schrieb am 15.07.2016 um 11:39 >>> in Nachricht <KL1PR04MB1205CDDF22D4A812AA099785E1330@KL1PR04MB1205.apcprd04.prod.outlook.com> > Hello, > > I have encountered with a problem in OpenLDAP2.4.44 with MDB backend. > I have two LDAP servers in Multi Master Mode MM1 and MM2. I am doing > the following steps: > 1. Both the LDAP DBs MM1 and MM2 have existing LDIF entries. > 2.Start MM1. Stop MM2. > 3. Add an entry A to MM1 using ldapadd. Stop MM1. > 4. Start MM2. Add LDIF entry B to MM2 using ldapadd. > 5. Start MM1. > > I am getting the below result. > The last added entry i.e. B in MM2 gets replicated to MM1. But LDIF > entry A doesn't get replicated to MM2. > But this scenario works fine in OpenLDAP 2.4.11 with BDB backend. It > replicates entry A to MM2 and entry B to MM1 correctly. > > How the above scenario with MBD in 2.4.44 can be avoided? As this is > very common scenario. It is a very common scenario that both LDAP servers are down at the same time? It is very common that one server is down? I think replication basically works like this: If a consumer gets an update from a provider, it is assumed to be up to date regarding that provider. I'm not sure whether your situation can be resolved. Ulrich > > Thanks > Gurjot Kaur > > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of the individual to whom it is addressed. It may > contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. > Aricent accepts no responsibility for loss or damage arising from the > use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
Attachment:
slapcatExportMM1_BDB.ldif
Description: slapcatExportMM1_BDB.ldif
Attachment:
slapcatExportMM1_MDB.ldif
Description: slapcatExportMM1_MDB.ldif
Attachment:
slapcatExportMM2_BDB.ldif
Description: slapcatExportMM2_BDB.ldif
Attachment:
slapcatExportMM2_MDB.ldif
Description: slapcatExportMM2_MDB.ldif