Issue
Sometimes there are pending items in the replication gap, but the replication is running smooth. This KB article describes how EVnearSync replicates the data of an open partition and how to execute a quick check that the replication of an open partition is running without any issues.
Solution
1. When EVnearSync starts a new replication cycle of an open partition it runs a query against to a particular Vault Store database to get 10000 oldest items awaiting replication:

SELECT TOP 10000
WatchFile.ItemName
,JournalArchive.TransactionID
,WatchFile.IdPartition
,JournalArchive.SavesetId
,JournalArchive.RecordCreationDate
FROM WatchFile
LEFT JOIN JournalArchive
ON WatchFile.ArchiveTransactionId = JournalArchive.TransactionID
ORDER BY JournalArchive.RecordCreationDate

The number of items getting from this query might be changed; as described in this article
2. Once EVnearSync finishes replication of all items from the query above it writes a triggered file (PartitionSecuredNotification.xml) into the root of the source EV partition. The triggered file contains the timestamp (date in UTC) of the most recently replicated item. EVnearSync may decrease the timestamp up to 5 seconds for safety reason. Here you can see an example of the triggered file:

<?xml version="1.0" encoding="utf-8" ?>
<PartitionSecuredNotification
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PartitionSecuredNotification.xsd">
<VendorName>QUADROtech</VendorName>
<VendorAppType>EVnearSync Replication</VendorAppType>
<PartitionSecuredDateTime>
2015-11-23T09:20:10+00:00
</PartitionSecuredDateTime>
<VendorTransactionId>V3.6</VendorTransactionId>
</PartitionSecuredNotification>

3. When the triggered file is processed by EV it is renamed from “PartitionSecuredNotification.xml” to “PartitionSecuredNotification.old”. There shouldn’t be a newer item in the Vault Store database than the timestamp in the triggered file; I.E. the SQL query above shouldn’t give you an item with the “JournalArchive.RecordCreationDate” (date in UTC) which is newer than the timestamp in the triggered file. This is shown on the example below:
JournalArchive.RecordCreationDate from the particular Vault Store database:

4. We have seen this is not always true. EVnearSync uses RecordCreationDate from Vault Store database for queueing items for replication. However this is not the only parameter used by EV when marking the items as secured. We have seen this inconsistency when the file system created date of a linked dataset in NTFS is newer that the timestamp in the triggered file. In this case EV doesn’t mark the items as secured and EVnearSync replicates the same items again. This is only a temporary issue because EVnearSync will continue in replication once a more recent item (newer item) is archived, i.e. it won’t be looping in a cycle. Here are the file properties of the dataset above (date in the local time):

All is shown in this summary:

 RecordCreationDate in Vault Store database   UTC  2015-11-23 09:20:05.813
 Created Date of the dataset in NTFS (UTC+1)  Local  2015-11-23 10:21:12
 Timestamp in the triggered file  UTC  2015-11-23T09:20:10+00:00

 

Print Friendly, PDF & Email