Hide Forgot
Description of problem: Consider we have a topology like Master replicating to slave. Master -> Salve When we promote Slave to become serve the Master role, if we assign the same replica ID(value of "nsDS5ReplicaId" ) as of the Master during promotion operation. The dummy entry(the "cn=start iteration" entry) do not get logged in the changelogdb file. But if we assign the different replicaID, the dummy entry gets logged in the changelogdb file. Version-Release number of selected component (if applicable): How reproducible: Frequently. Steps to Reproduce: 1.Create the Master and Salve topology where master replicating to the Slave. Master -------------------> Slave nsDS5ReplicaId: 10 nsDS5ReplicaId: 65535 ----> Original =========================================== Master <No aggrement now> Salve(Now become new master after promotion) nsDS5ReplicaId: 10( which is same as the master replica ID) Note: In this scenario, it doesn't create a changelogdb file along with the Dummy entry ============================================ Master <No aggrement now> Salve(Now become new master after promotion) nsDS5ReplicaId: 20( which is same as the master replica ID) Note: In this scenario, it creates a changelogdb file along with the Dummy entry. =========================================== 2.Make sure that both Master and Slave are on sync. 3.Delete the replication agreement. 4. Promote the Slave to serve the Master role. Promotion steps are given below. - Delete Supplier DN (cn=suppdn,cn=config) from Slave - Delete “cn=replica” entry for the suffix “o=USA” using ldapmodify. As a result, it will delete the changelog file. Ex: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config changetype: delete - Modify the cn=o=USA ,cn=mapping tree,cn=config entry as below EX: dn: cn=o=USA,cn=mapping tree,cn=config changetype: modify replace: nsslapd-state nsslapd-state: backend dn: cn=o=USA,cn=mapping tree,cn=config changetype: modify delete: nsslapd-referral - Recreate the “cn=replica” entry for the suffix as below. EX: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config changetype: add objectClass: nsds5replica objectClass: top nsDS5ReplicaRoot: o=USA nsDS5ReplicaType: 3 nsDS5Flags: 1 nsDS5ReplicaId: 10 ----> <Please assign the same “nsDS5ReplicaId value what master was having. In my case, Original master replica ID was 10.> nsds5ReplicaPurgeDelay: 1 nsds5ReplicaTombstonePurgeInterval: -1 cn: replica 5. Restart slapd process. Now Slave become Master. Actual results: It will not create any change log file and also will not create any dummy entry like below to mark the last change it was received ever. But if we assign a different replica ID( value of "nsDS5ReplicaId" attribute, for example "20" instead of "10"), we will see this entry being getting created along with the changelogdb file. dbid: 4eb10ac20004000a0000 replgen: 1320225977 Wed Nov 2 14:56:17 2011 csn: 4eb10ac20004000a0000 uniqueid: 00000000-00000000-00000000-00000000 dn: cn=start iteration operation: delete Expected results: It should create a chnagelogdb file along with the dummy entry if we assign the same replica ID as of it master which it does in case of a new replica ID assignment. Additional info:
Upstream ticket: https://fedorahosted.org/389/ticket/16
marking as screened because it has been cloned upstream
If a Consumer is prompted to Master, changelog needs to be enabled. If replicas exist on the Consumer server even if it is a read only replica, "notify_replica" is called. Via the notify call, the "dummy" change is logged in the changelog regardless of the replica ID. dbid: 4f186abd000000010000 replgen: 1327009803 Thu Jan 19 13:50:03 2012 csn: 4f186abd000000010000 uniqueid: 00000000-00000000-00000000-00000000 dn: cn=start iteration operation: delete Then, removing the read-only-replica removes the changelog and recreating a writable replica regenerate a new changelog, which does not include the "dummy" change any more. That's said not having the change in the promoted new master's changelog is not a problem.