Bug 750767 - 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.
Summary: After promotion of a Slave to Master, the dummy entry do not get logged in th...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: 389
Classification: Retired
Component: Replication - General
Version: 1.2.1
Hardware: ia64
OS: All
unspecified
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.10
TreeView+ depends on / blocked
 
Reported: 2011-11-02 10:45 UTC by Jyoti ranjan das
Modified: 2015-01-04 23:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-19 23:00:16 UTC


Attachments (Terms of Use)

Description Jyoti ranjan das 2011-11-02 10:45:20 UTC
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:

Comment 1 Martin Kosek 2012-01-04 13:17:48 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/16

Comment 2 Rich Megginson 2012-01-10 17:58:54 UTC
marking as screened because it has been cloned upstream

Comment 3 Noriko Hosoi 2012-01-19 23:00:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.