Bug 750767
| Summary: | After promotion of a Slave to Master, the dummy entry do not get logged in the new changelogdb file in Slave if it is assigned with the same replica ID(value of "nsDS5ReplicaId") as of it master. | ||
|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Jyoti ranjan das <jyoti-ranjan.das> |
| Component: | Replication - General | Assignee: | Rich Megginson <rmeggins> |
| Status: | CLOSED NOTABUG | QA Contact: | Chandrasekar Kannan <ckannan> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.2.1 | CC: | benl, nhosoi |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | ia64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-19 23:00:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 743970 | ||
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.
|
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: