Replication best practices
This section covers the best practices for replication based on our observations in production environments.
Purging obsolete replicas
About this task
By default, the PingDirectory server retains replicas for every server that has been part of a given topology. Over time, this can lead to an accumulation of obsolete replicas in your topology, which can increase the complexity of replication and negatively impact reliability.
To purge these obsolete replicas by default, you can set the replication-purge-obsolete-replicas
global configuration property to true
.
If you set |
Steps
-
To set
replication-purge-obsolete-replicas
totrue
, rundsconfig set-global-configuration-prop
, as in the following example:Example:
bin/dsconfig set-global-configuration-prop \ --set replication-purge-obsolete-replicas:true
About the dsreplication
command-line utility
The following points involve some security practices that apply to replication. For specific questions, 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. Use the recorded commands to develop scripts to set up and configure replication.
Scripts invoking the dsreplication
utility in non-interactive mode check the return code from the dsreplication
process. A non-zero return code indicates a failure.
To exclude output messages from the dsreplication
utility, use the --quiet
option to suppress them.
By default, the utility fails if one or more warnings are issued during the command execution. To suppress warnings, use the --ignoreWarnings
option.
This option is required when using |
Concurrent Use
With the exception of using the dsreplication
utility with the status
subcommand, the dsreplication
subcommands cannot execute 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. For best practices, avoid making concurrent configuration changes.
Status
Using the dsreplication
utility with the status
subcommand requires the Replication Servers to provide monitoring information. This can lead to a delay before the output of dsreplication
status
displays. By default, dsreplication
displays the status for all replicated domains with the exception of the special domains of the schema and the server registry.
Select a particular base distinguished name (DN) for dsreplication
status
if multiple base DNs are configured for replication.
Avoid invoking dsreplication
status
too often, such as 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 does not refresh every time the monitor is queried.
Do not use the status
subcommand for collecting performance metrics. It is best to use the Periodic Stats Logger plugin for replication-related information.
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. Use the --topologyFilePath
option to specify a file with a series of hosts and ports in the topology.
For example, 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 generates with the manage-topology export
command.
Replication subcommand logs
To preserve important troubleshooting and support information, PingDirectory Server logs dsreplication
subcommand executions, grouped by name, in the logs/tools
directory. By default, the server retains the output from the last 10 executions for each subcommand (such as status
, enable
, and initialize
). You can use these logs to review or troubleshoot the execution of a specific subcommand within the retention window.
The retention policy for these logs is not configurable. |
If a dsreplication
subcommand returns a non-standard result code, such as in the event of an error, the server generates a special log file:
-
Published to the
logs/tools
directory -
Named according to the result code and timestamp of the execution
-
Compressed and retained indefinitely
Check these logs first to more quickly and effectively determine a root cause.
These non-standard logs should be created by the server infrequently and contain valuable information for support technicians. Don’t delete these files unless necessary. When you run the |