Unlike ActiveClusterâ„¢, with ActiveDR the serial number of a volume in the remote pod will be different from the serial number of the corresponding volume in the local pod. This allows us to manage the remote pod volumes independently and prevents hosts applications and multipathing software from mistakenly treating the source and target volumes as the same volume.
To minimize the RTO in the event of a failover, it is recommended to prepare the remote site beforehand. This will also help with creating scripts to perform automatic failover and failback as many script parameters like host names and volume serial numbers will be known.
In preparation for failover, we will pre-connect hosts to the write-disabled volumes at the DR site (in the demoted pod). This allows devices and paths to be pre-discovered and pre-created on the DR hosts to make the overall failover process shorter and simpler. Though hosts can be connected to the target pod volumes, these volumes will be read-only while the target pod is in a demoted state.
The following steps prepare the DR site for failover as well as test the successful failover to the DR database.
It is assumed that database installation pre-requisite steps like creating OS users and groups, setting kernel parameters to the same values as PROD, Grid Infrastructure installation have already been performed.