PingDirectory

Topology-management tools

Because PingDirectory server topology-management tools like dsreplication and remove-defunct-server feature internal retries, external deployment automation scripts are not required to incorporate retries. This approach mitigates transient failures and makes servers more robust in automated environments.

To support this approach, dsreplication and remove-defunct-server include a --retryTimeoutSeconds option, which specifies a timeout value for the entire command. If the command fails, it is retried until the timeout value is reached. The command is not aborted if the timeout expires mid-execution, so it is guaranteed to be executed at least once. The default value of zero indicates the command does not have a timeout and is not retried upon initial failure.

The remove-defunct-server tool can also be used to complete the following tasks:

  • Remove an online server.

    Because a server runs as a container’s main process, and because shutting down a server re-spins the container, this task was impossible to complete in deployment automation environments that use containers. Automation scripts often resorted to hacks like impersonating an offline server by taking down the LDAP connection handler. In environments where security concerns prevented the use of LDAP, removing an online server was never an option.

  • Remove servers without forcing a topology primary when you do not have a quorum majority of online severs.

    The topology registry uses a primary-secondary architecture in which all write requests are chained through a single write-primary. When a primary could not be nominated, the topology becomes read-only. To work around this issue, a single server had to be forced as a primary to apply changes.

  • Remove servers concurrently.

The --ignoreOnline option can be used to remove an online server, and the --retryTimeoutSeconds option can be used to increase robustness in concurrent environments.

Finally, dsreplication enable provides internal support for a seed server before the replication topology exists. To prevent the creation of separate islands of replicating servers when simultaneously enabling replication on multiple hosts with a topology JSON file, the server that appears first in lexicographical order in the topology JSON file is designated as the seed server. When enabling replication on the seed server itself with the topology JSON file, it stops and returns a ERROR_SEED_AND_TARGET_SERVER_ARE_THE_SAME code. This precaution avoids deadlocking a dsreplication process when replication is invoked concurrently. On the seed server itself, deployment automation scripts can treat this code as being successful.