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
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
directory server to one or more target servers.
The Directory 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.