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.
- Click System.
- Select Replication.
- 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
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.