This topic describes failover of replicated state.

Replication recreates objects on the target system in a replica that preserves object relationships and naming on the target server without interfering with active objects on the system. Objects within a replica are read-only and disabled until a replica is failed over, at which point they can be activated. VDBs and dSources within a replica can be used as the source for provisioning new VDBs.


A replica contains a set of replicated objects. These objects are read-only and disabled while replication is ongoing. To view replicated objects, look under namespace in the CLI. Or in the GUI:
  1. Click System.
  2. Select Replication.
  3. Under Received Replicas, select the replica.

On this screen, you can browse the contents of replicas, as well as failover or delete individual replicas. As described in the Replication Overview topic, databases (dSouces and VDBs) and environments are included within the replica.

Deleting or failing over a replica will sever any link with the replication source. Subsequent incremental updates will fail, requiring the source to re-establish replication. Failover should only be triggered when no further updates from the source are possible, as in a disaster scenario.

Multiple replicas can exist on the system at the same time. Active objects can exist in the system alongside replicas without interfering with replication updates. You can also use VDBs and dSources within a replica as a source when provisioning. For more information, see Provisioning from Replicated Data Sources or VDBs.

Failover and Conflict Resolution

The retention policy is not replicated.  As such, and objects that are failed over will inherit the default retention policy(of 1 week).  As such, if the retention policy on the replication source was a longer duration this could cause the inadvertent removal of snapshots.  Its recommended to check the default retention policy and adjust as necessary until the retention policies from the replication source can be added.

To activate the objects in a replica, you must first fail over the replica. This will sever replication and move the objects to the live system, where they can be manipulated in the same fashion as other objects on the system.

Objects that are failing over can conflict with objects in the live system, due to identical names. For example, Groups will conflict if the failing over Group has the same name as a Group in the live system, as will most other objects including Environments, dSources, and VDBs. By default, active objects with conflicting names will cause an error at the time of failover. The error message will indicate which object(s) have conflicting names.

For all other object types, because the replica objects are read-only, you must rename the active objects before the failover operation can complete successfully.

Given that conflicting names prevent failover from succeeding, best practices in a disaster recovery situation are to leave the target system completely passive with no active objects until the time that a failover is required.

Once a replica is failed over, the objects are active but will be automatically disabled.

Enabling Databases and Environments

Objects may refer to states (IP addresses, mount paths, etc) that differ between the source and target system. Because of this, all databases and objects within a replica automatically start in the disabled state after a failover. This allows the administrator to alter configuration prior to enabling databases and environments, without the system inadvertently connecting to invalid systems.

After failover is complete, you must explicitly enable all dSources, VDBs, and environments. If you need to change any configuration for the target environment, you can do so prior to enabling the objects. In the event that a failing-over environment is consolidated with a live system environment, it must be refreshed before all of it's databases can be used.

Restoring Policies and Users

Policies and users are not replicated or backed up, meaning that you must recreate them on the target after a failover. There is no built-in mechanism to automate this within Delphix. It is recommended that you back up all users and policies using the CLI, web services, or other manual means so that you can recreate them on the target system after failover.

Related Links