Changing the source capture delay for recoveries - assure_mimix - 10.0

Assure MIMIX Operations Guide

Product type
Software
Portfolio
Integrate
Product family
Assure
Product
Assure MIMIX™ Software
Version
10.0
Language
English
Product name
Assure MIMIX
Title
Assure MIMIX Operations Guide
Copyright
2023
First publish date
1999
Last updated
2024-03-12
Published on
2024-03-12T11:06:36.794496

A replication recovery is additional processing, initiated as needed by database or object replication processes, that automatically attempts to correct a detected replication error without placing replication activity for the affected object or file on hold. A target journal inspection recovery attempts to correct a problem with a replicated object on the target node that was modified by users or programs other than MIMIX.

Some recovery actions initiated by replication processes and target journal inspection may require synchronizing objects or data between the source and target nodes. The recovery action gathers the needed information from the source node and submits a journal entry to correct the detected error or changed object. If synchronization is necessary, replication manager processes use the Source capture delay (SRCCAPDLY) policy to determine how long to wait between detecting the need for a replication recovery and capturing the affected file records, attributes, authorities, or the entire object from the source node.

The policy has two delay settings, one for recoveries during normal replication, and one for recoveries during the application testing phase of a virtual switch. (Both settings are ignored during the recovery phase of a virtual switch). You can change either setting if needed.

When a delay is configured for either setting, the delay starts with the first error detected for the object or record being replicated. During the delay time, the recovery action is not processed and subsequent recovery actions for the same type of problem for the same object or file record range are not tracked for the duration of the delay. When the delay time is reached, a journal entry requesting the recovery synchronization is placed into the journal stream and enough information for the tracked object or record range is captured from the source node and sent to the target so that the tracked recovery action and any additional recovery actions requested during the delay can be processed.