Replication is traditionally used to provide recovery in the event of disaster, where a datacenter or site is completely destroyed. Delphix replication may not be the only recovery solution in this scenario; to determine whether it meets your requirements, consult the Backup and Recovery Strategies for the Delphix Engine topic.

In a disaster recovery scenario, the target is kept in a passive state until the source system is lost. At this point, a failover is performed that breaks subsequent replication updates and activates objects so that you can manage them on the target side.

You can reconfigure environments on the target prior to failover if the infrastructure uses a different network topology or set of systems. Whether or not this is required depends on the nature of the failure at the primary site. If only the Delphix Engine is affected, and all of the source databases and target environments are unaffected, then the target can enable dSources and VDBs and reconnect to the original systems. If, on the other hand, the failure also destroyed the source and target systems, then those environments will have to be adjusted to point to the new systems on the target side. If there is not a 1:1 mapping, then you can migrate the VDBs to new systems on the target, and you can detach dSources and attach them to the standby system in the target environment.

Follow the best practices below to simplify failover and meet performance expectations in the event of a disaster:

• To the extent possible, the failover system should mirror the primary system
  
  • Target hosts and systems should exist at the target that match those at the source
  • The Delphix Engine should be provisioned with identical resources
  • The network and storage topologies should be the same
• Maintain a 1:1 relationship between source and targets
• The target should remain passive and not be actively used for other workloads
• Configuration of non-replicated objects, such as policies and users, should be retrieved via the command line interface (CLI) and saved so that they can be recreated after failover.

The Delphix Engine allows for VDBs to be provisioned from replicated dSources and VDBs, as described in  Provisioning from Replicated Data Sources or VDBs. This allows dSources to be linked in a single central location and geographically distributed so that developers can provision VDBs remotely without having to sync from the source database in multiple locations.

In this environment, replication is never broken and failover never performed, unless the motivation for distribution is eliminated but remote VDBs need to be preserved. You can refresh remote VDBs as long as the parent objects continue to exist on the source. If they are deleted, then remote VDBs will continue to function but cannot be refreshed.

Because there is no failover, this topology can support more complex topologies such as 1-to-many and many-to-1. Currently, replication can only replicate objects that exist in the primary namespace.  So the following are/are not supported:

• A -> B -> C :  You can replicate from A -> B.  But on B, it is not possible, nor supported, to create a replication specification with objects in the replication namespace that are desired to be replicated to C.
• A -> B -> (replica provision) -> C : In this scenario you can replicate from A -> B.  Then on B replica provision a VDB into the primary namespace. Finally add that object into a replication specification to replicate to C. Note: B can only replicate objects that exist in the primary(live) namespace to C.

For geographical distribution, follow these best practices:

• Because each replication stream induces load on the source system:
  
  • Minimize the number of simultaneous replication updates
  • If possible, avoid heavy VDB workloads on the source
• Provision only from sources that are effectively permanent. Otherwise, remote VDBs cannot be refreshed once the source is deleted.
• Provision additional storage capacity on the target
  
  • Remotely provisioned VDBs can consume shared storage on the target even when the parent is deleted on the source

You can use replication to perform one-time migration of resources from one Delphix Engine to another. While the hypervisor provides tools to move virtual appliances between physical systems, there are times when migration is necessary, such as:

• Migrating between different physical storage
• Consolidating or distributing workloads across Delphix Engines

In these cases, you can use replication to copy a subset of objects across asymmetric topologies.

For migration, follow these best practices:

• Send full updates, followed by incremental updates, until the time required for incremental updates meets your downtime window
• Disable all objects to be migrated on the source, to ensure that they are not actively changing
• Send a final incremental update before failing over the target
• After failover, destroy any migrated objects on the source, or the entire engine