The following points involve some security practices as applies to replication. For specific questions, please contact your authorized support provider.
  • Developing Scripts. The dsreplication utility maintains the history of executed dsreplication commands with the full command-line arguments in the logs/tools/dsreplication.history file. The recorded commands may be used to develop scripts to set up and configure replication.

    Scripts invoking the dsreplication utility in non-interactive mode should check the return code from the dsreplication process. A non-zero return code indicates some sort of failure.

    If output messages from the dsreplication utility are not desired, use the --quiet option to suppress them.

    The utility, by default, fails if one or more warnings are issued during the command execution. Warnings can be suppressed using the --ignoreWarnings option. For example, this option is required when using dsreplication with non-fully-qualified host names (for example, localhost), otherwise dsreplication will fail. In production environments, use of this flag is strongly discouraged.

    The dsreplication utility also provides an --ignoreLock option that specifies that the tool should continue processing in non-interactive mode or in scripts even if the replication topology has been locked by another invocation of dsreplication. However, this option should be used with caution.

  • Concurrent Use. With the exception of the dsreplication status subcommand, the dsreplication subcommands cannot be executed concurrently. The command-line utility locks the replication topology at one or more servers to prevent accidental configuration changes caused by multiple dsreplication subcommands running at the same time. It is best to avoid concurrent configuration changes in general.

  • Status. The dsreplication status subcommand requires the Replication Servers to provide monitoring information. This can lead to a delay before the output of dsreplication status is displayed. By default, dsreplication will display the status for all replicated domains (with the exception of the special domains of the schema and the server registry).

    It is recommended to select a particular base DN for dsreplication status if multiple base DNs are configured for replication.

    It is also recommended to avoid invoking dsreplication status too often (more than once every 15 seconds) or from multiple locations at the same time. Some of the information displayed by dsreplication status is based on monitor information that is not refreshed every time the monitor is queried.

    The status subcommand should not be used for collecting performance metrics. It is best to rely on replication-related information captured by the Periodic Stats Logger plugin.

  • Topology Tasks. The dsreplication tool allows specifying more than one server in a topology to act as the host for other servers for the enable and initialize actions. The --topologyFilePath option can be used to specify a file with a series of hosts and ports in the topology. 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. This file is generated with the manage-topology export command.