Real Failover to DR site

ActiveDR

Audience
Public
Product
FlashArray
FlashArray > Purity//FA
Content Type
User Guides
Source Type
Documentation

A failure at the production site might necessitate failover to the DR site. The nature of the failure can range from the entire site going down to just a few components or systems going down. The call to failover to the DR site is a technical as well as a business decision. The Oracle database may or may not be up when the call to failover is taken.

ActiveDR does not automatically or transparently failover to the DR FlashArray upon loss or unavailability of the PROD FlashArray. The ActiveDR failover process for applications and hosts must be triggered by the administrator. In the previous sections, we saw the command-line equivalent of each of the GUI actions was performed. It is quite straightforward to create scripts that would automate the failover and failback process.

Once a disaster is determined or declared, and a decision to failover has been made, the administrator would typically perform the following steps to failover an Oracle database and application:

  1. Stop all applications on PROD site, if they are still up
  2. Stop all Oracle databases on the PROD site
  3. Stop all ASM instances, that would unmount all ASM disk groups.
  4. Promote the DR pod. This will make the DR pod writable by the databases and applications
  5. If the FlashArray is not impacted by the failure and is accessible, demote the PROD pod, preferably using the quiesce option
  6. If required, make the necessary changes to the network load balances/DNS server to redirect connections to the DR site
  7. Start ASM instances in the DR site, verify all disk groups are mounted
  8. Start Oracle databases on the DR site
  9. Start applications on the DR site.

    As we can see, none of the steps listed above can be called "configuration" steps. That's because all configuration steps were one-time in nature, and were already performed in the failover preparation phase.

    One of the nice features of ActiveDR is that the API/CLI commands to do a test failover is the same as doing a real failover. The main difference is that in a test failover, the PROD pod is also in promoted status, and continues to send the replication stream to DR site. This stream is not applied to the promoted DR pod and is staged on the DR FlashArray for later application.