Replication concepts

Delphix replication allows you to copy objects from one Engine (referred to as a source Engine) to another Engine (referred to as a target Engine).

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 that will be explained in detail:

• Received Replicas or Namespaces: Once replication is complete, the target Engine will create 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 replication takes place, you must enable the databases and environments on the target engine. This step ensures the configuration of these objects is correct and will ensure 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. You may view replicated objects both in the Delphix Engine UI as well as the CLI. To view received replicas:

1. On the target Engine, navigate to ‘System’. Then select Replication.

2. Under Received Replicas, select the replica.

On this screen, you can browse the contents of replicas, as well as failover or delete individual replicas.

Deleting or failing over a replica will break 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. Various replication use cases are also 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 Provisioning from Replicated Data Sources or VDBs.

Failover and conflict resolution

To activate the objects in a replica, you must first fail over the replica. This will disconnect the replication connection and move 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, active objects with conflicting names will cause an error at the time of failover. 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 replication 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. 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.