Learn how to start reverse direction (\BACKUP -> \PROD) in an HPE Shadowbase Sizzling-Hot-Takeover (SZT) or bi-directional configuration, when only the primary direction (\PROD -> \BACKUP) has previously been running.
HPE NonStop servers can be configured to take advantage of geographic redundancy with HPE Shadowbase replication software. HPE NonStop servers provide software and hardware redundancy in their core characteristics. Shadowbase software provides the geographical redundancy to a business continuity environment by keeping two geographically diverse systems in synchronization with extremely low latency. The latency factor is determined by the customer’s requirements or SLA for guaranteeing delivery to the \BACKUP (or STANDBY) node of any pertinent data.
During new HPE Shadowbase product implementations, we have seen a rash of activity related to the following scenario. A customer deploys Shadowbase software in an SZT bi-directional configuration in a business continuity environment. In an SZT environment, the application tends to be active on one node with replication keeping the remote node in sync; however, bi-directional replication is configured to facilitate a fast failover in the event of an issue.
In some circumstances, when the reverse \BACKUP->\PROD direction attempts to start at the CURRENT AUDITTRAIL EOF, after only \PROD->\BACKUP has been active for some time, the algorithm in Shadowbase replication to prevent replication oscillation (ping-pong) causes the following error to result in EMS:
17-10-09 11:31:50 \BACKUP.$COLL GRAVIC.100.V63 002050 COLLECTOR
WILL START AT PEER CONSUMER SYNC POSITION
-> ADT 058943, RBA 0002603294720
The reverse direction replication is looking for the audit trail (AA058943, RBA 0002603294720) which is no longer on the system. You may have run your respective xxCU script before attempting to start the \BACKUP->\PROD reverse direction, and still encounter this scenario.
The following two options describe how to resolve this scenario, with the current product release T1122H06^AAG plus all earlier releases.
Option 1 is applicable if you CANNOT shut down the \PROD->\BACKUP thread for any reason, and is much simpler.
Set COLL ADTSTARTTIME to valid value (10 minutes prior to current wall clock time) (OCT 06 2017, 09:30:00)
SET COLL ADTSTARTEOF OFF
PURGE THE RESTARTFILE for COLL for (BACKUP to PROD).
PURGE the CONS TRACKTX files, for (BACKUP to PROD).
In xxAMON set TACL PARAM SBCOLLMYSTART 3 before start audmon command.
Start BACKUP to PROD check EMS for SBCOLLMYSTART 3 message and ADTSTARTTIME position message, and then make sure EOF current processing on COLL with stats command.
Option 2 is applicable if you have authority to briefly ‘bounce’ the \PROD->\BACKUP replication.
Shut down PROD direction.
Restart PROD to refresh the translogs to current for this direction.
Do not do anything else to config for (PROD to BACKUP).
PURGE THE RESTARTFILE for COLL (BACKUP to PROD).
Purge the CONS TRACKTX files, for (BACKUP to PROD).
Start BACKUP to PROD.
As always, if you foresee needing to exercise this activity in the near future, and you have a question, or any other question related to Shadowbase Support, then feel free to contact us.
[End of document]
Note: Customers often ask us, What is involved in deployment of a Shadowbase project? We created an outline that helps define the steps involved in such a project. Please note that this outline is not all-inclusive, and specific customer situations will demand a more customized response. Therefore, only the most common steps are outlined in Shadowbase Deployment Project Steps.
Note: We understand that you may ask us questions such as, Just how fast can Shadowbase software move my data? and How much overhead will the Shadowbase data replication engine incur? While we strive to be easy to work with and communicate openly, we generally do not publish performance metrics regarding the HPE Shadowbase product suite. Please visit Performance Metrics for more information.
Please reference our Newsletter Disclaimer.