Initialization

Replica initialization transfers a copy of the backend containing the replication domain to a target server. You should perform this after replication is enabled with the dsreplication initialize subcommand. There is no impact on the source server during this process.

When enabling or initializing servers, the --topologyFilePath option can be used with dsreplication to specify a file with a series of hosts and ports available in the topology that can be used as source servers.

This option is used in place of specifying host 1, port 1. When the hosts file is used for an enable or initialize action, the servers in the file are tried sequentially until the new server is successfully enabled or added. The rest of the servers in the file are ignored. This ensures that a host server is always available for replication. This file is generated with the manage-topology export command.

dsreplication initialize

The recommended approach for replica initialization. The dsreplication initialize subcommand performs the most efficient copy of data needed to initialize one or more replicas on a target server. Existing data on the target server replica is lost and the backend containing the base DN is taken offline on the target server during the initialization.

Binary copy

The database copy method involves copying database backup files from the source PingDirectory server to one or more target servers. The PingDirectory server provides tools necessary for backing up and restoring backends. Using server-root/bin/backup, create a backup of the backend containing the replicated base DN. The backup files must then be transferred to the target servers and restored individually with server-root/bin/restore. There are additional considerations when using database copy as the means to initialize a target replica:

If encryption is enabled on the servers, then a database bin/encryption-settings export followed by bin/encryption-settings import must be performed on the encryption-settings backend.
When using database copy to initialize a server that has been offline longer than the replication purge delay, the database copy of the replicationChanges, schema, and adminRoot backends are required.

Import/export LDIF

The import/export LDIF method is the most flexible approach, as it works well in environments where target replicas are configured differently than the backend containing the data (for example, the target replica has different indexes than the source server). The process involves exporting the backend data as LDIF from the source server and importing the LDIF into the target servers. Replicas can be initialized locally while the server is offline or online through remote access. For more information, see Importing and exporting data.