Delphix replication copies objects from one CD engine (the source engine) to another CD engine (the target engine). DCT orchestrates this process, providing a unified view of replication policies and replicated objects across all connected engines.
Replication recreates objects from the source engine onto the target engine in a replica, also known as a namespace, that preserves object relationships and naming on the target engine without interfering with its active objects. Objects within a replica are read-only and disabled until the 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. Below are key concepts for replication:
-
Received replicas or namespaces: Once replication is complete, the target engine creates a received replica, also known as a namespace. This is a copy of objects that are related via a grouping.
-
Failover and conflict resolution: Certain objects may require changes to resolve conflicts prior to completing a replication failover. Names of replicated objects should be unique for replication to complete successfully.
-
Enabling databases and environments: Once failover takes place, you must enable the databases and environments on the target engine. This step ensures the configuration of these objects is correct and verifies that replication has correctly copied the necessary object relationships from the source engine.
Received replicas or namespaces
A replica contains a set of replicated objects, such as dSources and VDBs. These objects are read-only and disabled while replication is ongoing. To view received replicas in DCT:
-
Navigate to Data > Policies > Replication and select a replication policy to view its replicated objects and execution history.
-
To view replica insights, navigate to Data > Policies > Replication > Replica insights.
Deleting or failing over a replica breaks the 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. Various replication use cases are described in Replication use cases.
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 Provision from replicated dSources or VDBs.
Failover and conflict resolution
To activate the objects in a replica, you must first fail over the replica. This breaks the link with the replication source and moves the objects to the live system, where they can be actively used.
During the replication failover, there may be objects that conflict between the source engine and the target engine. For example, groups will conflict if the failing-over group has the same name as a group in the live system, as well as environments, dSources, and VDBs. By default, failover attempts to resolve these conflicts automatically. Some objects cannot be resolved automatically; in these scenarios, 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 failover is required.
Once a replica is failed over, the objects are active but will be automatically disabled. The next section describes enabling these objects after failover is complete.
Enabling databases and environments
Objects may refer to states (IP addresses, mount paths, etc.) that differ between the source and target engines. Because of this, all databases and objects within a replica are automatically disabled 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.
-
To enable environments, in DCT, navigate to Home > Infrastructure Connections.
-
To enable data objects, in DCT, navigate to Data > Data Management > dSources or Data > Data Management > VDBs.
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 its databases can be used.