[389-users] Data inconsitency during replication

Rich Megginson rmeggins at redhat.com
Fri Oct 28 17:24:17 UTC 2011


On 10/20/2011 12:45 AM, Das, Jyoti Ranjan (STSD) wrote:
>
> Hi,
>
> I am new to 389 directory server. Could you please help me in the 
> below mentioned query?
>
> Thank you very much in advance.
>
> Problem statement:
>
> Data loss during the replication between Supplier and consumer when 
> master changelog db file is being deleted due to some reason , 
> consumer is imported with some stale data and consumer doesn't want 
> initialization during the new replication agreement. The test scenario 
> is given below.
>
> Test scenario:
>
> Steps:
>
> 1)Topology
>
> Supplier -----------Replication agreement-----------------> Hub
>
> Both replicas are in sync at this time as mentioned below.
>
> Let's take this sample example: Five entries has been added starting 
> from CSN1 to CSN5
>
> 2)Take a db2ldif with "-r" option from the Hub replica.
>
> 3)Add another 5 entries in the supplier. Let's take their CSN numbers 
> are starting from CSN6 to CSN10
>
> 4)Delete the replication agreements
>
Before or after CSN6 to CSN10 have been replicated to the Hub?
>
> 5)Delete the master changelog db file from the changelogdb directory.
>
Supplier or Hub?
>
> 6)Add another 5 entries in the supplier. Let's take their CSN numbers 
> are staring  from CSN11 to CSN15
>
> 7)Import the ldif file  taken in Step-2 in the Hub replica(  it's a 
> initialization of consumer with the stale data)
>
> 8)Create the replication agreement between master and hub with the "do 
> not initialize" option.
>
> 9)Now we will see the data loss starting from CSN6 to CSN14. Only 
> entry with CSN15 will be replicated to the consumer and also will 
> continue further with successful replication
>

> Questions:
>
> */1)/**/Is this a correct approach in this scenario to continue with 
> replication even if there are data losses instead of halting the 
> replication? /*
>
> From the code analysis:
>
> File: " ldapserver/ldap/servers/plugins/replication/cl5_api.c"
>
> If the requested CSN number is now found in the changelog db file and 
> also not there in the purge list, it makes the following assumption 
> and continues with replication
>
> /* there is a special case which can occur just after migration - in 
> this case,
>
>   the consumer RUV will contain the last state of the supplier before 
> migration,
>
>   but the supplier will have an empty changelog, or the supplier 
> changelog will
>
>   not contain any entries within the consumer min and max CSN - also, 
> since
>
>   the purge RUV contains no CSNs, the changelog has never been purged
>
>   ASSUMPTIONS - it is assumed that the supplier had no pending changes 
> to send
>
>   to any consumers; that is, we can assume that no changes were lost 
> due to
>
>   either changelog purging or database reload - bug# 603061 - 
> richm at netscape.com */
>
> */                 Is it a correct approach in this scenario to halt 
> the replication with a fatal error message in the error log file?/*
>
Probably, but then this code would have to be a lot smarter to figure 
out that the problem is due to stale data being imported into the 
consumer.  Please file a bug with exact steps to reproduce this problem.
>
> *//*
>
> Regards,
>
> Jyoti
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20111028/f9d772fb/attachment.html 


More information about the 389-users mailing list