Reinitializing a Topology

This section describes how to analyze your topology to determine which systems need to be reinitialized. It also describes the methods you can use to reinitialize your replication topology.

Determining What to Reinitialize

When you reinitialize your topology, you take a good copy of the data from a supplier and overwrite the bad data on the consumers in the topology. Before you reinitialize your topology, determine which systems are unsynchronized and need to reinitialized. This critical step can prevent your from wasting time by overwriting data that is already synchronized.

For example, the following figure illustrates a topology where replication is broken on hub 1.

Because hub 1 provided data to consumers A and B, you need to reinitialize hub 1, consumer A, and consumer B.

In the following example, consumers A and B also receive updates from hub 2.

Consumers A and B may be synchronized with the supplier of the reinitialized replica because they receive updates from both hubs. Their status depends on which replica you select to reinitialize your topology. If you use RUVs to ensure that you have the latest changes, then these replicas may be up-to-date and you may not need to reinitialize consumers A and B.

Doing a Clean Reinitialization

All of the reinitialization methods copy unnecessary data, for example data that contains values that were deleted or that maintain state information or other historical data. This unnecessary data makes the entry larger in disk. Also, the entry state information may need to be purged. If the root cause of the replication problem is related to this state information, the data is still present in the database and can cause another replication error. To avoid importing this unnecessary and potentially problematic data, you can do a clean reinitialization of your topology.

When you do a clean reinitialization, you create a clean master copy of the data that contains smaller databases, indexes, and empty change logs. A clean reinitialization uses less disk space and takes less time because it does not make backup copies of the database files. It also reduces index fragmentation, which can reduce performance. However, it requires you to stop the server that is being cloned to ensure that the database files are in a coherent state.

To Create Clean Master Data in Directory Server

1. Stop the master server.
2. Export the database contents using the dsadm command.

   Specify the -Q option so that replication information is not included in the export.

   # dsadm export -Q instance-path suffix-DN  /tmp/clean-export.ldif

3. Reimport the exported data to the same master server using the dsadm command.

   # dsadm import instance-path /tmp/clean-export.ldif suffix-DN

4. Restart the master server.

   The master server now contains clean data, meaning it contains smaller databases, indexes, and empty change logs.

5. Import the clean master data, to all of the other servers in your system.

To Reinitialize a Suffix Using the DSCC

This method requires a replication agreement between the supplier and the consumers suffixes. Use this method to reinitialize a single suffix or to reinitialize many small suffixes.

1. On the supplier server, log in to DSCC.
2. Click the Directory Servers tab, then click the Suffixes tab.
3. In the Suffixes tab, select the suffix or suffixes that you need to reinitialize.

   Select Initialize Suffix from Data from the drop-down menu.

4. In Step 1, select Initialize Using Existing Replication Agreements.
5. In Step 2, specify the supplier suffix from which you want to copy the data.
6. Verify that the import is complete by checking the errors log of the consumers.