A virtual switch procedure provides the framework in which you can perform application testing on a backup node in a MIMIX environment. The SWTVRT procedure is created by default as one of the procedures created automatically when a new application group is created.
Phases of the virtual switch procedure
The SWTVRT procedure runs multiple steps to perform these major functions, which can be considered as virtual switch phases:
-
Precheck. The first set of steps check the configuration to ensure that no restrictions exist, that requirements are met, and check for conditions that would otherwise end the virtual switch. These operations can also be performed in advance by using the virtual switch precheck procedure, PRECHKVRT.
-
Setup. These steps change the MIMIX environment to prepare for testing and affect objects on the target node of data groups within the application group when that node is the designated test node for the virtual switch. These operations begin with step MXSETVRTS, which changes the replication status to Virtual switch starting and clears any retained information about any objects changed in the previous virtual switch of the application group. For the affected data groups, active audits are ended and prevented from running and the database apply and object apply processes are ended. Also, the multithreaded database apply job is ended (when configured) or access path maintenance is ended (if enabled and allowed by the configuration). Subsequent replicated transactions are queued for apply processes. Any foreign key constraints previously disabled by MIMIX are enabled on the target objects. Status of target journal inspection jobs on the test node are checked and are set to not issue notifications while testing is in progress for the affected data groups. For files on the target node that are eligible for replication, journaling is changed, if necessary, to use both before and after journaling images.
-
Test. The step MXSETVRTT changes the replication status to Virtual switch testing, which indicates that the environment is ready for you to begin testing applications on the backup node that you identified as the test node. You are responsible for starting, testing, and ending the application on the test node. While you are testing, the procedure waits for a user reply to a waiting message for step MXVRTRCY. When you have completed testing, respond to this message to indicate that you are ready for recovery to begin.
-
Recover. When step MXVRTRCY runs, it changes the replication status to Virtual switch recovery. The remaining steps return the test node to its original purpose as a backup node in the MIMIX production environment. During recovery, all foreign key constraints are disabled on files on the test node that are eligible for replication. Triggers are disabled on all target node files eligible for replication. If necessary, files on the test node which had their journal image settings changed during the setup phase are changed back to their original settings. Target node processes are started beginning with the last processed entry for the receiver and sequence number, and apply processes begin applying the queued transactions that accumulated during testing. Constraints are enabled on the target node if the data group is not configured to allow MIMIX to perform target constraint management. Target journal inspection is changed to allow sending notifications again. If there are any remaining objects that could not be recovered, they will be reflected in the user interface as requiring manual correction through replication activity entries, notifications, or both. Then replication statuses will no longer reflect a virtual switch status. Finally, prioritized audits are submitted to verify the objects changed on the target node during testing, these audits run regardless of whether prioritized auditing is enabled.
For more information about steps within the SWTVRT procedure, see the Assure MIMIX Administrator Reference book.
Automatic error recovery during a virtual switch
Even though the apply processes are ended during a virtual switch, other replication processes are active and continue to automatically check for replication problems. The automatic recovery actions for detected problems are not processed until the recovery phase of the virtual switch.
During the test phase of a virtual switch, any recovery actions that require synchronizing objects or data between the source and target nodes will capture source objects according to the “during virtual switch” setting of the Source capture delay policy. The delay time must be met before the synchronization request for the affected object or records is submitted into the journal stream. The recovery action is not processed until the recovery phase of the virtual switch. The policy values are configurable. For more information about selecting an appropriate source capture delay value during a virtual switch, see online help topics or see the Assure MIMIX Operations book.
Source node objects with successful recovery actions are flagged for prioritized auditing. A prioritized auditing request is submitted at the end of the virtual switch procedure regardless of whether you have enabled prioritized auditing.
If a recovery action is not successful, the activity entry for the affected object or file is changed to a replication error status For objects not within the scope of replication that are related to replicated objects, an error notification will be sent.
Viewing recovery actions for target objects changed during a virtual switch
When using the MIMIX portal application in the Assure UI portal, you can use actions available in the Application Groups portlet and Data Groups portlet to view the following information:
-
Object Correction Activity window - lists objects for which recovery actions exist and shows status of the recovery actions. The window can be filtered to those only for a virtual switch. There may be multiple problems or changes for an object but the window lists only one row per object per data group.
-
From the Application Groups portlet, you can use the Virtual Switch Activity action for an application group to view the list objects changed on the test node and their recovery actions. After the recovery phase of the virtual switch begins, you will be able to see any objects that recovery actions were unable to recover.
The ability tor view the objects changed during a virtual switch and the recovery actions are not available in the native user interface.