Re: [389-users] Data inconsitency during replication

[Rich Megginson <rmeggins@xxxxxxxxxx>]

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@xxxxxxxxxxxx */

 

                 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users