This topic describes how to configure data replication between CD engines. In DCT, replication is configured through replication policies that contain options such as the replication schedule, the target engine, and the selected objects that will be replicated. To create and manage replication policies, navigate to Data > Policies > Replication in DCT.

For step-by-step guidance on using the DCT interface to create replication policies, see Managing Replications.

Requirements

  • Version requirements: The replication target can be on the same or newer version than the replication source. For version compatibility details, see Forward Compatible Replication (FCR).

  • Engine communication: The target CD engine must be reachable from the source engine. For online replication modes, both engines must be registered and reachable from DCT.

  • Storage allocation: The target CD engine must have sufficient free storage to receive the replicated data.

  • Privilege requirements: The user must have administrative privileges on the source and the target engines. In DCT, your user and Access Groups must have permission to view and manage replication policies and related datasets.

Configure the network

Delphix replication uses a private network protocol to communicate between two CD engines. You may specify a network interface to run replication by configuring routing to direct traffic over a particular interface. 

The replication network protocol uses TCP port 8415. If there is a firewall between the source and target that is blocking this port, there are two possible solutions:

  1. Enable port 8415 on the firewall to allow connections from the source to the target.

  2. Replication can connect through a SOCKS proxy if one exists.

Port 1080
SOCKS port 1080 is used by default but can be overridden.
The following SOCKS proxy configuration is performed directly on the CD engine. You can access connected engines from DCT via Data Infrastructure > Data Engines.

Example: SOCKS proxy configuration (CD engine CLI)

dlpx-engine> service proxy
				dlpx-engine service proxy> update
				dlpx-engine service proxy update *> set socks.enabled=true
				dlpx-engine service proxy update *> set socks.host=10.2.3.4
				dlpx-engine service proxy update *> set socks.username=someuser
				dlpx-engine service proxy update *> set socks.password=somepassword
				dlpx-engine service proxy update *> commit
				dlpx-engine service proxy> get
				type: ProxyService
				https:
				type: ProxyConfiguration
				enabled: false
				host: (unset)
				password: (unset)
				port: 8080
				username: (unset)
				socks:
				type: ProxyConfiguration
				enabled: true
				host: 10.2.3.4
				password: ********
				port: 1080
			username: someuser

Create a replication policy in DCT

  1. In DCT, navigate to Data > Policies > Replication.

  2. Click + Replication Policy.

  3. Select a mode, such as Replicate Engine Data for standard replication.

  4. Enter the policy Name and optional Description.

  5. Select the Target Engine, which is a DCT-connected CD engine that will receive the replicated data.

  6. Under Replication Objects, select the objects that you want to replicate, such as dSources, VDBs, groups, or the entire engine.

  7. Configure parameters:

    • Automated Replication: Optionally enable a schedule with interval and time of day.

    • Traffic Options: Enable encryption, limit bandwidth, and set the maximum number of network connections.

    • Replica Tags: Automatically apply tags to replicas created by this policy.

  8. Review the summary and click Save Policy.

For detailed instructions with screenshots, see Managing Replications.

Replication policy options

There are several configuration options for your replication policies. These give you more granular control on options such as when replication will run, how much bandwidth it may use, and which objects are replicated.

The following configurable options are static and cannot be configured at run-time. You can set these configurations while a replication job is being executed, but the values will be applied only after the next execution.

  • Automated replication: Define a schedule to automatically run replication at specified intervals. By default, automated replication is disabled, meaning that you must trigger replication updates manually.

  • Traffic options: Various traffic and bandwidth options are available.

    • Encrypting traffic: By default, replication streams are unencrypted, which provides maximum performance on a secure network. Enabling encryption allows you to secure traffic during replication.

      Encrypting the replication stream will consume additional CPU resources and may limit the maximum bandwidth that can be achieved. During replication, the CD engine will negotiate an SSL connection with its server peer to use TLS_AES_128_GCM_SHA256 as the cipher suite and TLSv1.3 as the protocol.

    • Network connections: Set the number of underlying network connections that can be used by replication.

    • Limiting bandwidth: By default, replication runs at the maximum speed permitted by the underlying infrastructure. This option allows you to specify the maximum bandwidth that replication can consume.

      When you replicate multiple datasets, your actual bandwidth usage may exceed the configured limit, potentially by up to 4x, due to system-level parallelization. To mitigate this, consider setting your bandwidth limit to a lower value than your network's maximum threshold, especially when bandwidth contention is a concern.

  • Replication objects: Select the objects that you want to replicate from the source engine to the target engine. Some selected objects may have dependencies, which are other objects that will be pulled into replication because they share data.

  • This is not guaranteed to be the full set of dependent objects. The full set of objects and their dependents will be calculated at the time of replication.

  • You cannot configure a replication policy without selecting an object, and the last object from a replication policy cannot be removed. If you need to remove the last object, you must delete the replication policy.

  • The object is removed from the replication target namespace only after a subsequent replication job is executed.

Object inclusion rules:

  • When replicating a group, all dSources and VDBs currently in the group, or added to the group at a later time, will be included.

  • Regardless of whether you select a VDB individually or as part of a group, the parent dSource or VDB (and any parents in its lineage) are automatically included.

  • This is required because VDBs share data with their parent object.

  • In addition, any environments containing database instances used as part of a replicated dSource or VDB are included as well.

  • When replicating individual VDBs, only those database instances and repositories required to represent the replicated VDBs are included. Other database instances that may be part of the environment, such as those for other VDBs, are not included.

  • CD engine-level non-data objects (Delphix users, roles, permissions, authorizations, policies, and database configuration templates) that are associated with selected objects will be automatically included during replication. They will not be shown on the selection interface.

The non-data objects listed above are CD engine objects. Replication includes associated objects on the target CD engine; it does not create or modify DCT users, roles, access groups, or permissions.

In DCT, the source VDB and its replica are separate objects for scoped-role assignments. Adding only the source VDB to a scoped role does not give users access to the replica before or after failover.

To give users access to the replica, use one of these approaches:

For instructions on assigning objects directly or by tag to a scoped role, see Objects: Refine permission to targeted objects.

  • Add both the source VDB and the replica to the scoped role.

  • Assign a tag to the VDB and the scoped role, and enable Include existing source tags on replicas for the replication policy. This option defaults to false for replication specifications created outside DCT.

Either approach lets users see the replica both before and after failover. For replica-tag settings, see Managing Replications. For an example, see DCT Permissions After Replication Failover (KBA12088). DCT bookmark replication is described in Replication interface.

Removing objects from a replication policy

You can remove individual objects, such as a VDB, from an existing replication policy without impacting other objects that remain in the policy. Removing an object does not affect the replication state or retention of any other dataset included in the policy.

When an object is removed:

  • The change is applied to the replication specification on the source.

  • The object is removed from the replication target engine only after the next replication job completes.

  • Remaining objects continue to replicate normally and are not re-transferred or modified.

  • If you later add the object back, the full dataset must be replicated again because the object is treated as new to the policy.

You cannot remove the final object from a replication policy. If the last object must be removed, delete the replication policy instead.

Target engine behavior

Additional configuration on the target engine is not needed. Replicated objects will appear in an alternate received replica (or namespace) that mirrors the original object layout.

To view replicated objects in DCT, navigate to Data > Policies > Replication and select the replication policy to view its source objects and execution history. You can also view replica details via Replica details.

You can create and manage objects on the target server without affecting subsequent updates, though this can cause conflicts on failover that require additional time to resolve. For disaster recovery use cases, it is recommended to keep the target passive and not create any local objects. This will avoid conflicts and guarantee a smooth failover operation.

Multiple sources can replicate to the same target, allowing for the flexible geographical distribution of data. This is not a recommended practice for disaster recovery, because it increases the probability of conflicts on failover and may oversubscribe resources on the target if multiple replicas are failed over and there is insufficient infrastructure to support the combined workloads.

Last updated
Oct 8, 2026