Information for troubleshooting replicationEdit online Use the troubleshooting information to identify the cause of various replication issues and resolve them. Replicated suffixThe replicated suffix must have the ibm-replicationcontext object class. Set the object class before you load your data in the database.Verify that suffixes and replication agreements existIf you experience errors with replication, use the idsldapsearch command to verify that your suffixes are configured to be replicated and that the replication agreements exist.Peer-to-peer replication errorIf you are running peer-to-peer replication, you might encounter the error "No such object occurred for replica." Follow the steps to resolve this problem.Insufficient access errorWhen replication returns an insufficient access error, the reason might be related to the version of IBM® Verify Directory on the consumer. Follow the steps to troubleshoot and work around this problem.Replication topology extended operation fails with result code 80After you run a replication topology extended operation, you might see an error message that the operation failed with result code 80. There are several reasons why this error might occur. Complete the checks that are required to ensure that this error is resolved.Replication command-line interface errorIf you have a master server that is configured to do replication, you might see a command-line interface error. This error occurs only on Windows™ operating systems. Follow the steps to resolve this error.Entries in LDIF file are not replicatedWhen you use the idsldif2db command with the -r yes option, you might find that entries are not being replicated. The -r yes option indicates that the entries in the file are to be replicated. Use the troubleshooting information to resolve the problem.Problem with cn=ibmpolicies subtreeA problem might occur with replicating or modifying the cn=ibmpolicies subtree, where this subtree becomes read-only or might not get replicated properly. Follow the steps to resolve this problem.Master server becomes unstable or stopsThe master server might become unstable or stop when it serves a larger number of replica servers. The reason might be because the master server ran out of resources. Follow the steps to resolve this issue.Stopping a multithreaded replication supplierIn a replication environment, abruptly stopping a supplier that uses multithreaded replication to accelerate replication between its consumers can cause problems. To avoid having replication-related errors, complete the specified steps before you stop a supplier server.Synchronizing directory servers in a replicated environmentIf directory servers in a replicated environment are out of synch, the replication queues might get blocked. To resolve this problem, you must resynchronize your replicated environment.Multimaster configurationsThe configuration must ensure that updates for the same entry or set of entries do not occur to several peer masters at the same time. The replication system can be configured in such a way that all writes go to one master except in the case of failover. Or, the system can be configured so that all writes for a specified subtree go to one master except in the case of failover.Options for replication filter and replication method are not availableWhen you create a master server in a replication topology, the options to specify replication filter and replication method are not available. This unavailability is a limitation of the Web Administration Tool. However, you can specify the filter and replication method options in a peer-to-peer replication.Consumer server that does not support SHA-2Replication between an IBM® Verify Directory, Version 6.3 or later supplier and a consumer server with an earlier version that does not support SHA-2 cannot be started.Replication lag due to high-frequency attribute changesHigh-frequency attribute changes can slow replication. Volatile attribute replication separates these changes from critical updates to improve performance.Parent topic: Replication issues