PingDS

Manual initialization

Manual initialization isn’t always required. Replication proceeds automatically over the network when replicas start from the same initial data. If this isn’t the case, manually initialize replication.

  • Unless you’re using Disaster recovery to repair a broken data set, initialization only succeeds when you restore data more recent than the replication purge delay.

    Make sure you’re restoring from recent data.

  • Test the initialization process to make sure you understand the duration and ramifications of the chosen initialization method.

    Use the results to make an evidence-based decision on whether to use backup/restore or export/import instead of online initialization.

How you initialize replication depends on your situation:

Initialization options
Use cases Recommendations

Replicas installed with same data

Nothing to do (no manual initialization required)

Evaluating DS software

Developing a directory solution

Plenty of bandwidth to replicate data

Initialize over the network

Limitations:

  • Transmits all data over the network, so requires ample bandwidth; can be a problem for slow links.

  • Rebuilds indexes and consumes significant system resources; can impact service performance.

New directory service, medium to large data set (> 1 million entries; limited bandwidth)

Initialize all replicas from LDIF

Limitations:

  • Rebuilds indexes and consumes significant system resources; can impact service performance.

  • Doesn’t correct bad data in the changelog database.

Existing directory service, medium to large data set (> 1 million entries; limited bandwidth)

Initialize from backup

Limitations:

  • All DS servers must be the same version. Backups are not guaranteed to be compatible across major and minor server releases.

  • Doesn’t correct bad data in the changelog database.

New backend

Create a backend, then one of:

Limitations:

  • The limitations depend on how you initialize the new backend, and are described above.

Broken data set

Disaster recovery

Limitations:

  • This method permanently loses recent changes.

  • Applications using the changelog must be reinitialized after you restore the data.

Initialize over the network

Review Initialization options before following these steps:

  1. Manually initialize replication using the replication protocol’s total update capability in one of these ways:

    1. Overwrite the data in all replicas with the data from the replica where the command runs:

      $ dsrepl \
 initialize \
 --baseDN dc=example,dc=com \
 --toAllServers \
 --hostname localhost \
 --port 4444 \
 --bindDN uid=admin \
 --bindPassword password \
 --trustStorePath /path/to/opendj/config/keystore \
 --trustStorePassword:file /path/to/opendj/config/keystore.pin \
 --no-prompt

    2. Initialize a single other replica, identified by its server ID, from the replica where the command runs:

      $ dsrepl \
 initialize \
 --baseDN dc=example,dc=com \
 --toServer ds-1 \
 --hostname localhost \
 --port 4444 \
 --bindDN uid=admin \
 --bindPassword password \
 --trustStorePath /path/to/opendj/config/keystore \
 --trustStorePassword:file /path/to/opendj/config/keystore.pin \
 --no-prompt

Initialize all replicas from LDIF

If you aim to initialize replicas with LDIF from a non-replicated environment, follow the steps in Disaster recovery instead.

Review Initialization options before following these steps:

Initialize each replica with the same LDIF:

  1. Stop the server.

  2. If desired, enable data confidentiality.

    Learn more in Data encryption and Encrypt External Changelog Data.

  3. Import the LDIF.

    Learn more in Import LDIF.

  4. Start the server.

Initialize from backup

Review Initialization options before following these steps:

  1. Stop the replica.

  2. Restore the backend from backup.

    Learn more in Restore.

  3. Start the replica.

    Replication replays changes from other replicas that have happened since the backup was created.