Data verification is a way of ensuring a level of data integrity for the replicated resource information after it has arrived at its destination. It ensures that the exact data replicated from the source is the exact data received at the destination.
When creating a resource replication rule and enabling data verification there is an option to ‘Verify maximum percentage of data during replication.’
This allows the users to specifically set the level of data integrity they wish to have as a percentage.
The percentage of data to be verified is based off the total amount of data which is included in the rule, which is the number of resources specified in the rule times the number of data classes selected in the rule.
In a situation where 10% verification has been selected on the resource replication rule, and nothing has changed causing the differential replication to send no data, there is still 10% more of the overall rule coverage which is checked during the verification phase. Additionally the source server does not resend the data immediately if it detects a hash difference, rather it marks it to be included in the next replication, even if the resource/data class combination has had no changes marked in the ResourceUpdateSummary table.
It does this by clearing the ‘ForwardDate’ and ‘VerifyDate’ column for that data set and switching it to NULL inside the ForwardingHistorySummary table. This NULL value will cause this set of data to be resent at next replication.
Once the destination server has validated a set of data, it is entered into the tableReplicationDataVerificationHistory table on the destination NS database.
The next time replication occurs it will know not to validate the resource/data records that already exist in the table.
Once the ‘Verify Date’ column inside the table for a particular dataset is greater than 10 days, the NS Daily schedule will set the ‘Verify Date’ value to ‘NULL’ when it is run. This will cause the dataset to be considered for data verification during any further resource replications.
The expiry time for validated data is set to 10 days by default, but is configurable through the core setting ‘ReplicationDataVerifyDaysThreshold’