Chapter 8
Managing Replication
Replication is the mechanism by which directory data is automatically copied from one Red Hat Directory Server (Directory Server) to another; it is an important mechanism for extending your directory service beyond a single server configuration. This chapter describes the tasks to be performed on the supplier servers and the consumer servers to set up single-master replication, multi-master replication, and cascading replication. This chapter includes the following topics:
- Replication Overview (page 308)
- Replication Scenarios (page 312)
- Handling Complex Replication Configurations (page 317)
- Configuring Single-Master Replication (page 326)
- Configuring Multi-Master Replication (page 330)
- Configuring Cascading Replication (page 343)
- Making a Replica Updatable (page 348)
- Deleting the Changelog (page 349)
- Initializing Consumers (page 350)
- Forcing Replication Updates (page 356)
- Replication over SSL (page 360)
- Replication with Earlier Releases (page 361)
- Using the Retro Changelog Plug-in (page 363)
- Monitoring Replication Status (page 366)
- Solving Common Replication Conflicts (page 370)
- Troubleshooting Replication-Related Problems (page 370)
For conceptual information on how you can use replication in your directory deployment, see the Red Hat Directory Server Deployment Guide.
Replication Overview
Replication is the mechanism by which directory data is automatically copied from one Directory Server to another. Updates of any kind - entry additions, modifications, or even deletions - are automatically mirrored to other Directory Servers using replication. This section contains information on the following replication concepts:
- Read-Write Replica/Read-Only Replica
- Supplier/Consumer
- Changelog
- Unit of Replication
- Replication Identity
- Replication Agreement
- Compatibility with Earlier Versions of Directory Server
Read-Write Replica/Read-Only Replica
A database that participates in replication is defined as a replica. There are two kinds of replicas: read-write or read-only. A read-write replica contains master copies of directory information and can be updated. A read-only replica refers all update operations to read-write replicas. A server can hold any number of read-only or read-write replicas.
Supplier/Consumer
A server that holds a replica that is copied to a replica on a different server is called a supplier for that replica. A server that holds a replica that is copied from a different server is called a consumer for that replica. Generally, the replica on the supplier server is a read-write replica and the one on the consumer server is a read-only replica. There are exceptions to this statement:
- In the case of cascading replication, the hub supplier holds a read-only replica that it supplies to consumers. For more information, refer to "Cascading Replication," on page 316.
- In the case of multi-master replication, the masters are suppliers and consumers for the same read-write replica. For more information, refer to "Multi-Master Replication," on page 313.
In Directory Server, replication is always initiated by the supplier server, never by the consumer. This operation is called supplier-initiated replication. It allows you to configure a supplier server to push data to one or more consumer servers.
Earlier versions of the Directory Server allowed consumer-initiated replication, where you could configure consumer servers to pull data from a supplier server.
Changelog
Every supplier server maintains a changelog. A changelog is a record that describes the modifications that have occurred on a replica. The supplier server then replays these modifications to the replicas stored on consumer servers or to other suppliers, in the case of multi-master replication.
When an entry is modified, a change record describing the LDAP operation that was performed is recorded in the changelog.
In Directory Server, the format of the changelog has changed. It is now only intended for internal use by the server. If you have applications that need to read the changelog, you need to use the Retro Changelog Plug-in for backward compatibility. For more information, refer to "Using the Retro Changelog Plug-in," on page 363.
Unit of Replication
The smallest unit of replication is a database. This means that you can replicate an entire database but not a subtree within a database. Therefore, when you create your directory tree, you must take your replication plans into consideration. For more information on how to set up your directory tree, refer to the Red Hat Directory Server Deployment Guide.
The replication mechanism also requires that one database correspond to one suffix. This means that you cannot replicate a suffix (or namespace) that is distributed over two or more databases using custom distribution logic. For more information on this topic, refer to "Creating and Maintaining Databases," on page 92.
Replication Identity
When replication occurs between two servers, the replication process uses a special entry, often referred to as the Replication Manager entry, to identify replication protocol exchanges. The Replication Manager entry, or any entry you create to fulfill that role, must meet the following criteria:
- It is created on the consumer server (or hub supplier) and not on the supplier server.
- You must create this entry on every server that receives updates from another server, meaning on every hub supplier or dedicated consumer.
- When you configure a replica that receives updates from another server, you must specify this entry as the one authorized to perform replication updates.
- When you configure the replication agreement on the supplier server, you must specify the DN of this entry in the replication agreement.
- This entry must not be part of the replicated database for security reasons.
- This entry, with its special user profile, bypasses all access control rules defined on the consumer server.
For more information on creating the Replication Manager entry, refer to "Creating the Supplier Bind DN Entry," on page 318.
Replication Agreement
Directory Servers use replication agreements to define their replication configuration. A replication agreement describes replication between one supplier and one consumer only. The agreement is configured on the supplier server. It specifies:
- The database to be replicated.
- The consumer server to which the data is pushed.
- The times during which replication can occur.
- The DN and credentials that the supplier server must use to bind (called the Replication Manager entry or supplier bind DN).
- How the connection is secured (SSL, client authentication).
- Any attributes that will not be replicated. (For information on fractional replication, refer to the Red Hat Directory Server Deployment Guide.)
Compatibility with Earlier Versions of Directory Server
The replication mechanism in current versions of Directory Server is different from the mechanism used in earlier versions (4.x) of Directory Server. Compatibility is provided through the following:
- Legacy Replication Plug-in - The Legacy Replication Plug-in makes Directory Server behave as a 4.x Directory Server in a consumer role. For information on how to implement legacy replication using this plug-in, refer to "Replication with Earlier Releases," on page 361.
- Retro Changelog Plug-in - The Retro Changelog Plug-in can be used when you want a Directory Server supplier to maintain a 4.x style changelog. This is sometimes necessary for legacy applications that have a dependency on the Directory Server 4.x changelog format because they read information from the changelog. For more information on the Retro Changelog Plug-in, refer to "Using the Retro Changelog Plug-in," on page 363.
Replication Scenarios
This section describes the most commonly used replication scenarios:
You can combine these basic scenarios to build the replication environment that best suits your needs.
Single-Master Replication
In the simplest replication scenario, the master copy of directory data is held in a single read-write replica on one server called the supplier server. The supplier server also maintains changelog for this replica. On another server, called the consumer server, you have as many read-only replicas as you like. Such scenarios are called single-master configurations. <Z_Online>Figure 8-1 shows an example of single-master replication.
Figure 8-1 Single-Master Replication
|
In this particular configuration, the ou=people,dc=example,dc=com suffix receives a large number of search requests. Therefore, to distribute the load, this tree, which is mastered on server A, is replicated to two read-only replicas located on server B and server C.
For information on setting up a single-master replication environment, refer to "Configuring Single-Master Replication," on page 326.
Multi-Master Replication
Directory Server also supports complex replication scenarios in which the same suffix (database) can be mastered on many servers. This suffix is held in a read-write replica on each server. This means that each server maintains a changelog for the read-write replica.
This type of configuration can work with any number of consumer servers. Each consumer server holds a read-only replica. The consumers can receive updates from all the suppliers. The consumers also have referrals defined for all the suppliers to forward any update requests that the consumers receive. Such scenarios are called multi-master configurations.
<Z_Online>Figure 8-2 shows an example of multi-master replication scenario with two supplier servers and two consumer servers.
Figure 8-2 Multi-Master Replication (Two Suppliers)
|
<Z_Online>Figure 8-3 shows a sample of multi-master replication scenario with four supplier servers and eight consumer servers. In this sample setup, each supplier server is configured with ten replication agreements to feed data to two other supplier servers and all eight consumer servers.
Figure 8-3 Multi-Master Replication (Four Suppliers)
Multi-master configurations have the following advantages:
- Automatic write failover when one supplier is inaccessible.
- Updates are made on a local supplier in a geographically distributed environment.
Replication, especially multi-master replication, works better over high speed links than over slow links, such as a WAN, in geographically distributed environments. |
For information on setting up multi-master replication with two supplier servers and two consumer servers, refer to "Configuring Multi-Master Replication," on page 330.
Cascading Replication
In a cascading replication scenario, one server, often called a hub supplier, acts both as a consumer and a supplier for a particular replica. It holds a read-only replica and maintains a changelog. It receives updates from the supplier server that holds the master copy of the data and, in turn, supplies those updates to the consumer. Cascading replication is very useful when you need to balance heavy traffic loads or have supplier servers based locally in geographically distributed environments.
<Z_Online>Figure 8-4 shows an example of cascading replication. This example shows a simple cascading replication scenario. You can create more complex scenarios with several hub suppliers.
Figure 8-4 Cascading Replication
|
For information on setting up cascading replication, refer to "Configuring Cascading Replication," on page 343.
You can combine multi-master and cascading replication. For example, in the multi-master scenario illustrated in <Z_Online>Figure 8-2, on page 314,, server C and server D could be hub suppliers that would replicate to any number of consumer servers. |
Handling Complex Replication Configurations
If you are configuring replication for a large number of servers and your configuration is relatively complex, for reasons of efficiency, you should proceed in the following order:
- On all consumer servers:
- On all hub suppliers:
- On all suppliers:
- Configure replication agreements on all suppliers:
- Configure replication agreements on all hub suppliers between the hub supplier and the dedicated consumers.
These sections contain a description of the tasks you need to perform to configure replication:
- Creating the Supplier Bind DN Entry
- Configuring Supplier Settings
- Configuring a Read-Write Replica
- Configuring a Read-Only Replica
- Configuring a Hub Supplier
- <Z_Online>Creating a Replication Agreement
Creating the Supplier Bind DN Entry
A critical part of setting up replication is to create the entry, referred to as the Replication Manager or supplier bind DN entry, that the suppliers will use to bind to the consumer servers to perform replication updates.
The supplier bind DN must meet the following criteria:
- It must be unique.
- It must be created on the consumer server (or hub supplier) and not on the supplier server.
- It must correspond to an actual entry on the consumer server.
- It must be created on every server that receives updates from another server.
- It must not be part of the replicated database for security reasons.
- It must be defined in the replication agreement on the supplier server.
For example, you could create an entry cn=Replication Manager,cn=config under the cn=config tree on the consumer server. This would be the supplier bind DN that all supplier servers would use to bind to the consumer to perform replication operations.
On each server that acts as a consumer in replication agreements, create a special entry that the supplier will use to bind.
This entry must not be part of the replicated database. For example, you could use cn=Replication Manager,cn=config. Make sure you create the entry with the attributes required by the authentication method you specify in the replication agreement.
- Stop the Directory Server. If you do not stop the server, the changes you make to the dse.ldif file will not be saved. See "Starting and Stopping the Directory Server," on page 37, for more information on stopping the server.
- Create a new entry, such as cn=replication manager,cn=config, in the dse.ldif file.
- Specify a userPassword attribute-value pair.
- If you have enabled the password expiration policy or intend to do so in the future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z, which means that the password will never expire.
- The final entry should resemble this example:
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: replication manager
sn: RM
userPassword: password
passwordExpirationTime: 20380119031407Z
- Restart the Directory Server. See "Starting and Stopping the Directory Server," on page 37, for more information on starting the server.
When you configure a replica as a consumer, you must use the DN of this entry to define the supplier bind DN.
Configuring Supplier Settings
On any server that holds the master copy of a replica, you must specify supplier settings.
To configure supplier settings:
- In the left navigation tree, highlight the Replication node.
- In the right pane, select the Supplier Settings tab.
- Check the Enable Changelog checkbox.
- Specify a changelog by clicking the "Use default" button, or click Browse to display a file selector.
- Set the changelog number and age parameters.
Configuring a Read-Write Replica
For each read-write replica on the supplier server, you must specify the appropriate replication settings.
To configure a read-write replica:
- In the left navigation tree, expand the Replication folder, and highlight the database to replicate.
- Check the Enable Replica checkbox.
- In the Replica Role section, select the Single Master or Multi-Master radio button.
- In the Common Settings section, specify a Replica ID (an integer between 1 and 254, both inclusive).
Configuring a Read-Only Replica
For each read-only replica on the consumer server, you must specify the appropriate replication settings.
- In the left navigation tree, expand the Replication folder, and then highlight the replica database.
- Check the Enable Replica checkbox.
- In the Replica Role section, select the Dedicated Consumer option.
- In the Common Settings section, specify a purge delay in the "Purge delay" field.
- In the Update Settings section, specify the supplier bind DN that the supplier will use to bind to the replica.
Configuring a Hub Supplier
In a cascading replication environment, configure the hub supplier as follows:
- In the left navigation tree, expand the Replication folder, and then highlight the database to replicate.
- Check the Enable Replica checkbox.
- In the Replica Role section, select the Hub radio button.
- In the Common Settings section, specify a purge delay in the "Purge delay" field.
- In the Update Settings section, specify the supplier bind DN that the supplier will use to bind to the replica.
Creating a Replication Agreement
This section explains how to create a replication agreement. You must create a replication agreement on the supplier server for each read-write replica that is supplied to a consumer server or a hub supplier.
Before you can create a replication agreement, you must have:
- Configured supplier settings on the server as described in "Configuring Supplier Settings," on page 320.
- Configured replication settings for suppliers as described in "Configuring a Read-Write Replica," on page 321.
- Configured replication settings for hub suppliers (if any) and consumers as described in "Configuring a Read-Only Replica," on page 322.
To create a replication agreement:
- In the navigation tree, expand the Replication folder, right-click the database to replicate, and select New Replication Agreement.
- In the first screen, fill in the name of your replication agreement. You may also fill in a description, such as Supplier1 to Supplier2, 4-way MMR.
- On the next screen, fill in the consumer hostname and port. Unless you have more than one instance of Directory Server configured, by default, there are no consumers available in the drop-down menu.
If you have enabled attribute encryption, you must use a secure connection in order for those attributes to be replicated. |
- Optionally, you can enable fractional replication. By default, all attributes are replicated to the consumer server. If you want to select attributes that will not be replicated to the consumer, enable fractional replication by checking the "Enable Fractional Replication" checkbox. Then, highlight the attribute (or attributes) in the "Included" column on the right, and click "Remove." All attributes that will not be replicated will be listed in the "Excluded" column on the left, as well as in the summary when you hae finished your replication agreement.
The consumer of this replication agreement must be a dedicated consumer for fractional replication to work as a safeguard against potential data integrity problems. This is not enforced at the time you make the replication agreement, but replication will fail if your consumer is not a read-only replica. See "Replication Overview," on page 308, for more information on read-only replicas and dedicated consumers. |
- The last screen is a summary of your replication agreement. Check that this is accurate, and hit "Done."
Configuring Single-Master Replication
This section provides information on configuring single-master replication. The steps described in this section provide a high level overview of the procedure you need to follow. Cross-references to the detailed task descriptions are provided at each step.
To set up single-master replication such as the configuration shown in <Z_Online>Figure 8-1, on page 313,, between supplier server A, which holds a read-write replica, and the two consumers server B and server C, which each hold a read-only replica, you need to perform the following procedures:
- Configuring the Read-Only Replica on the Consumer Server
- Configuring the Read-Write Replica on the Supplier Server
- Initializing the Replicas for Single-Master Replication
Configuring the Read-Only Replica on the Consumer Server
- Create the entry corresponding to the supplier bind DN on the consumer server if it does not exist. This is the special entry that the supplier will use to bind to the consumer.
- In the Directory Server Console, select the Directory tab, and create an entry. For example, you could use cn=Replication Manager,cn=config.
- Specify a userPassword attribute-value pair.
- If you have enabled the password expiration policy or intend to do so in future, you must remember to disable it to prevent replication from failing due to passwords expiring.
- Click Save to save the replication settings for the replica.
- Repeat these steps for every read-only replica in your replication configuration.
Configuring the Read-Write Replica on the Supplier Server
Initializing the Replicas for Single-Master Replication
You can initialize the read-only replicas from the Replication Agreement Wizard or at anytime afterwards. For information on initializing read-only replicas, refer to "Initializing Consumers," on page 350.
When you have finished, the replication agreement is set up.
Configuring Multi-Master Replication
This section provides information on configuring multi-master replication. In a multi-master configuration, many suppliers can accept updates, synchronize with each other, and update all consumers. The consumers can send referrals for updates to all masters. The steps described in this section provide a high-level overview of the procedures you need to follow for two sample multi-master replication scenarios.
- Configuring 2-Way Multi-Master Replication
- Configuring 4-Way Multi-Master Replication
- Preventing Monopolization of the Consumer in Multi-Master Replication
Configuring 2-Way Multi-Master Replication
To set up multi-master replication such as the configuration shown in <Z_Online>Figure 8-2, on page 314,, between two suppliers server A and server B, which each hold a read-write replica, and two consumers server C and server D, which each hold a read-only replica, you need to perform the following procedures:
- Configuring the Read-Only Replicas on the Consumer Servers
- Configuring the Read-Write Replicas on the Supplier Servers
- Initializing the Replicas for Multi-Master Replication
Configuring the Read-Only Replicas on the Consumer Servers
Perform these steps on each consumer server, server C and server D:
This is the special entry that the supplier will use to bind. The entry must not be part of the replicated database. |
- Click Save to save the replication settings for the replica.
- Repeat these steps for every read-only replica in your replication configuration.
Configuring the Read-Write Replicas on the Supplier Servers
Perform these steps on each supplier server, server A and server B:
This is the special entry that the supplier will use to bind. The entry must not be part of the replicated database. |
- On server A and server B, specify the replication settings for the multi-mastered read-write replica.
- On server B, set up the following replication agreements:
- One with supplier server A, where server A is declared as a consumer for the replica. During this operation, do not initialize server A from server B if you have already initialized server B from server A in Step 4.
- One for each consumer servers, server C and server D.
Once you have completed these procedures, server A and server B have mutual replication agreements, which means that they can accept updates from each other. |
When you have configured the servers holding the read-write replicas, the necessary replication agreements, and the servers holding the read-only replicas, you are ready to initialize replication. You can perform this task when you create the replication agreements on the supplier servers or at any time afterwards.
Initializing the Replicas for Multi-Master Replication
In the case of multi-master replication, you should initialize replicas in the following order:
- Ensure one supplier has the complete set of data to replicate. Use this supplier to initialize the replicas on the other masters in the multi-master replication set.
- Initialize the replicas on the consumer servers from any one of the two suppliers.
For information on initializing replicas, refer to "Initializing Consumers," on page 350.
Configuring 4-Way Multi-Master Replication
Directory Server supports 4-way multi-master replication. To set up multi-master replication such as the configuration shown in <Z_Online>Figure 8-3, on page 315,, between four supplier servers, server M1 through server M4, that each hold a read-write replica, and eight consumer servers, server C1 through server C8, that each hold a read-only replica, you need to perform the following procedures:
- Configuring the Read-Only Replicas on the Consumer Servers
- Configuring the Read-Write Replicas on the Supplier Servers
- Initializing the Replicas for Multi-Master Replication
If you have more than 10 databases running with replication, you may see performance degradation. Also, if you have more than 20 replication agreements on a supplier, you may see performance degradation. If you need to support that many consumers, you may have to introduce one or more hub replicas between your supplier(s) and consumers. See "Configuring Cascading Replication," on page 343. |
Configuring the Read-Only Replicas on the Consumer Servers
Perform these steps on each consumer server, server C1 through server C8:
This is the special entry that the supplier will use to bind. The entry must not be part of the replicated database. |
- Click Save to save the replication settings for the replica.
- Repeat these steps for every read-only replica in your replication configuration.
Configuring the Read-Write Replicas on the Supplier Servers
Perform these steps on each supplier server, server M1 through server M4:
This is the special entry that the supplier will use to bind. The entry must not be part of the replicated database. |
- Set up replication agreements on all the supplier servers:
- On server M1, set up the following replication agreements: one with supplier server M2, where server M2 is configured as a consumer for the replica; one with supplier server M4, where server M4 is configured as a consumer for the replica; and one for each consumer servers, server C1 through server C8.
- On server M2, set up the following replication agreements: one with supplier server M1, where server M1 is declared as a consumer for the replica; one with supplier server M3, where server M3 is declared as a consumer for the replica; and one for each consumer servers, server C1 through server C8.
- On server M3, set up the following replication agreements: one with supplier server M2, where server M2 is declared as a consumer for the replica; one with supplier server M4, where server M4 is declared as a consumer for the replica; and one for each consumer, server C1 through server C8.
- On server M4, set up the following replication agreements: one with supplier server M3, where server M3 is declared as a consumer for the replica; one with supplier server M1, where server M1 is declared as a consumer for the replica; and one for each consumer servers, server C1 through server C8.
Once you have completed these procedures, all four servers - server M1 through server M4 - have mutual replication agreements, which means that they can accept updates from each other. |
When you have configured the servers holding the read-write replicas, the necessary replication agreements, and the servers holding the read-only replicas, you are ready to initialize replication. You can perform this task when you create the replication agreements on the supplier servers or at any time afterwards. For information on the order and procedure for initializing read-only replicas, refer to "Initializing the Replicas for Multi-Master Replication," on page 335, and "Initializing Consumers," on page 350.
During this operation, do not try to reinitialize the servers. For example, do not initialize server M1 from server M2 if you have already initialized server M2 from server M1.
Initializing the Replicas for Multi-Master Replication
In the case of multi-master replication, you should initialize replicas in the following order:
- Ensure one supplier has the complete set of data to replicate. Use this supplier to initialize the replica on the other supplier in the multi-master replication set.
- Initialize the replicas on the consumer servers from either of the four suppliers.
For information on initializing replicas, refer to "Initializing Consumers," on page 350.
Preventing Monopolization of the Consumer in Multi-Master Replication
One of the features of multi-master replication is that a supplier acquires exclusive access to the consumer for the replicated area. During this time, other suppliers are locked out of direct contact with the consumer. If a supplier attempts to acquire access while locked out, the consumer sends back a busy response, and the supplier sleeps for several seconds before making another attempt.
A problem can arise if the locking supplier is under a heavy update load or has a lot of pending updates in the changelog. If the locking supplier finishes sending updates and then has more pending changes to send, it will immediately attempt to reacquire the consumer and will most likely succeed, since the other suppliers usually will be sleeping. This can cause a single supplier to monopolize a consumer for several hours or longer.
Two attributes address this issue:
These two attributes may be present in the nsds5ReplicationAgreement object class, which is used to describe replication agreements. You can set the attributes at any time by using changetype:modify with the replace operation. The change takes effect for the next update session if one is already in progress.
If you set either attribute to a negative value, Directory Server sends the client a message and an LDAP_UNWILLING_TO_PERFORM error code. |
The two attributes are designed so that the nsds5ReplicaSessionPauseTime interval will always be at least 1 second longer than the interval specified for nsds5ReplicaBusyWaitTime. The longer interval gives waiting suppliers a better chance to gain consumer access before the previous supplier can re-access the consumer.
- If either attribute is specified but not both, nsds5ReplicaSessionPauseTime is set automatically to 1 second more than nsds5ReplicaBusyWaitTime.
- If both attributes are specified, but nsds5ReplicaSessionPauseTime is less than or equal to nsds5ReplicaBusyWaitTime, nsds5ReplicaSessionPauseTime is set automatically to 1 second more than nsds5ReplicaBusyWaitTime.
If Directory Server has to automatically reset the value of nsds5ReplicaSessionPauseTime, the value is changed internally only. The change is not visible to clients, and it not saved to the configuration file. From an external viewpoint, the attribute value appears as originally set.
Replica busy errors are no longer logged by default because they are usually benign. If you want to see them, turn on the replication error log level.
Configuring Cascading Replication
This section provides information on setting up cascading replication. The steps described in this section provide a high-level overview of the procedures you need to follow, and cross-references to the detailed task descriptions are provided at each step.
To set up cascading replication such as the configuration shown in <Z_Online>Figure 8-4, on page 316,, between the supplier on server A, which holds a read-write replica; the consumer/supplier on hub server B, which holds a read-only replica; and the consumer on server C, which holds a read-only replica, you need to perform the following procedures:
- Configuring the Read-Only Replica on the Consumer Server
- Configuring the Read-Only Replica on the Hub Supplier
- Configuring the Read-Write Replica on the Supplier Server
- Initializing the Replicas for Cascading Replication
Configuring the Read-Only Replica on the Consumer Server
To configure the read-only replica in a consumer server:
- On the consumer server, create the entry corresponding to the supplier bind DN if it does not exist. This is the special entry that the supplier will use to bind.
- On the consumer server, specify the replication settings for the read-only replica.
When you have configured the replicas on each server and the necessary replication agreements among servers, you can initialize the read-only replicas on the hub supplier and on the consumer. You can perform this task from the Replication Agreement Wizard while you are configuring the supplier server and the hub supplier server or at any time afterwards.
Configuring the Read-Only Replica on the Hub Supplier
Perform these steps on the hub supplier that receives replication updates from the supplier and propagates them to consumers:
This is the special entry that the supplier will use to bind. The entry must not be part of the replicated database. |
Configuring the Read-Write Replica on the Supplier Server
Perform these steps on the supplier server that holds the original copy of the database:
Initializing the Replicas for Cascading Replication
In the case of cascading replication, you should initialize replicas in the following order:
- Use the supplier server to initialize the replica on the hub supplier.
- From the hub supplier, initialize the replica on the consumer.
For information on initializing replicas, refer to "Initializing Consumers," on page 350.
Making a Replica Updatable
To make a read-only server writable, follow this procedure:
- Make sure there are no updates in progress.
- Stop the supplier server.
- Open the Directory Server Console for the read-only replica.
- In the configuration tab, select Replication, and then, on the right pane, enable changelog.
- Select the suffix, and, in the Replica Settings tab, change Replica Role to Single Master, and assign a unique replica ID.
- Save your changes, and restart the server.
Deleting the Changelog
The changelog is a record of all modifications on a given replica that the supplier uses to replay these modifications to replicas on consumer servers (or suppliers in the case of multi-master replication). In the event of a supplier server going offline, it is important to be able to delete the changelog because it no longer holds a true record of all modifications and, as a result, should not be used as a basis for replication. Once you have deleted the changelog, you can initialize your consumers and begin the replication process afresh. To delete the changelog, you can either remove it or move it to a new location.
This section contains the information for the following procedures:
Removing the Changelog
You can remove the changelog using the Directory Server Console. To remove the changelog from the supplier server:
- In the Directory Server Console, select the Configuration tab.
- Select the Replication Agreements folder in the left navigation tree and then the Supplier Server Settings tab in the right pane.
- Clear the Enable Changelog checkbox.
Moving the Changelog to a New Location
To delete the changelog while the server is still running and continuing to log changes, you simply move the changelog to a new location. By moving the changelog, a new changelog is created in the directory you specify, and the old changelog is deleted. If you change the location of the changelog, it is as if you are reinitializing it, which in turn requires consumer reinitialization.
For example, you could move the changelog from the default location of
serverRoot/slapd-serverID/changelogdb
serverRoot/slapd-serverID/newchangelogdb
Initializing Consumers
Once you have created a replication agreement, you must initialize the consumer; that is, you must physically copy data from the supplier server to the consumer servers. This section first describes consumer initialization in detail and then provides instructions on the two different methods for initializing consumers. This section is divided into the following parts:
- When to Initialize a Consumer
- Online Consumer Initialization Using the Console
- Manual Consumer Initialization Using the Command-Line
- Filesystem Replica Initialization
When to Initialize a Consumer
Consumer initialization involves copying data from the supplier server to the consumer server. Once the subtree has been physically placed on the consumer, the supplier server can begin replaying update operations to the consumer server.
Under normal operations, the consumer should not ever have to be initialized again. However, if the data on the supplier server is restored from backup for any reason, then you should reinitialize all of the consumers supplied by it.
You can either initialize the consumer online using the Console or manually using the command-line. Online consumer initialization using the Console is an effective method of initializing a small number of consumers. However, since each replica is initialized in sequence, this method is not suited to initializing a large number of replicas. Online consumer initialization is the method to use when you initialize the consumer while configuring the replication agreement on the supplier server.
Manual consumer initialization using the command-line is a more effective method of initializing a large number of consumers from a single LDIF file.
Online Consumer Initialization Using the Console
Online consumer initialization using the Console is the easiest way to initialize or reinitialize a consumer. However, if you are replicating across a slow link, this process can be very time-consuming, and you may find manual consumer initialization using the command-line to be a more efficient approach. Refer to "Manual Consumer Initialization Using the Command-Line," on page 352, for more information.
Performing Online Consumer Initialization
To initialize or reinitialize a consumer online:
- On the supplier server, on the Directory Server Console, select the Configuration tab.
- Expand the Replication folder, then expand the replicated database. Right-click the replication agreement, and choose Initialize Consumer from the pop-up menu.
Online consumer initialization begins immediately. You can check the status of the online consumer initialization on the Summary tab in the Status box. If online consumer initialization is in progress, the status shows that a replica is being initialized.
To update this window, right-click the replicated database icon in the navigation tree, and choose Refresh Replication Agreements. When online consumer initialization finishes, the status changes to reflect this.
For more information about monitoring replication and initialization status, see "Monitoring Replication Status," on page 366.
Manual Consumer Initialization Using the Command-Line
Manual consumer initialization using the command-line is the fastest method of consumer initialization for sites that are replicating very large numbers of entries. However, the manual consumer initialization process is more complex than the online consumer initialization process. We suggest you use the manual process whenever you find that the online process is inappropriate due to performance concerns.
This section is divided into the following parts:
- Manual Consumer Initialization Overview
- Exporting a Replica to LDIF
- Importing the LDIF File to the Consumer Server
Manual Consumer Initialization Overview
To initialize or reinitialize a server manually:
Exporting a Replica to LDIF
You can convert the replica to LDIF using one of the following three procedures:
- When you create a replication agreement by selecting "Create consumer initialization file" in the Initialize Consumer dialog box of the Replication Agreement Wizard.
- From the Directory Server Console at any time by right-clicking the replication agreement under the Replication folder and choosing "Create LDIF File" from the pop-up menu.
- From the command-line by using the export command as described in "Exporting to LDIF from the Command-Line," on page 161.
Importing the LDIF File to the Consumer Server
You can import the LDIF file which contains the supplier replica contents to the consumer server by using the import features in the Directory Server Console or by using either the ldif2db script or ldif2db.pl script. Both import methods are described in "Importing from the Command-Line," on page 155.
If you use the ldif2db script, remember to bind using the supplier bind DN configured on the consumer server.
Filesystem Replica Initialization
If you have a very large database, such as one with several million entries, it can take an hour or more to initialize a consumer from the Console or even with manual initialization. To save time, you can use filesystem replica initialization.
Directory Server has the capability to initialize a replica using the database files from the supplier server. This avoids the need to rebuild the consumer database and can be done at essentially the speed of the network between the two servers by transferring the files with FTP or NFS, for example. Instead of sending entries via LDAP to replica servers, filesystem replica initialization populates the new database on the destination server by "backing up" the supplier database on one server and "restoring" the database on the destination server.
This method of initializing consumers is especially useful in replication over wide-area networks or over networks with slow or unstable connections.
For smaller databases, it is recommended that you still use the manual initialization or initialize consumers from the Console.
Initializing the Consumer Replica from the Backup Files
- Enable replication on the backend as a dedicated consumer.
- If you already have a replication agreement to that host and port, than replication should resume immediately after running the restore script. Otherwise, create the replication agreement on your source server (or whatever server you will use as the supplier), and select the "Do not initialize consumers at this time" radio button.
- At the command prompt, change to the following directory on the source Directory Server:
cd serverRoot/slapd-serverID
- From the command-line, run the db2bak utility, and archive your current directory installation. You can also create a new backup by hitting the "Back Up Directory Server" button in the Tasks tab of the Directory Server Console and then putting the name of your archive directory in the "Directory:..." field.
- Copy the archived files to a directory on your destination server, such as archiveDirectory.
- At the command prompt, change to the following directory on the destination Directory Server:
cd serverRoot/slapd-serverID
- On the destination server, restore the archives with the bak2db script, using the optional -n parameter to specify the backend instance name. This -n parameter is similar to the -n used with ldif2db and db2ldif. For example:
./bak2db /redhat/servers/slapd-serverID/archiveDirectory -n
userRoot
Replication will begin on schedule as soon as the destination server is restarted.
For more information on using these scripts, see the Red Hat Directory Server Configuration, Command, and File Reference.
Forcing Replication Updates
When you stop a Directory Server involved in replication for regular maintenance, when it comes back online, you need to ensure that it gets updated through replication immediately. In the case of a supplier in a multi-master environment, the directory information needs to be updated by the other supplier in the multi-master set. In other cases, when a hub supplier or a dedicated consumer is taken offline for maintenance, when they come back online, they need to be updated by the supplier server.
If you have configured replication agreements to keep the supplier server and the consumer server in sync always, this is not sufficient to bring back up-to-date a server that has been offline for over five minutes. The reason is that, with the "Always Keep in Sync" option, the server generates a replication operation for every update operation it processes. However, if this replication operation cannot be performed because the consumer is offline, the operation times out after 10 minutes.
The procedures described in this section can only be used when replication is already set up and consumers have been initialized. |
To ensure that directory information will be synchronized immediately when a server comes back online, you can use either the Directory Server Console on the supplier server that holds the reference copy of the directory information or a customizable script.
Forcing Replication Updates from the Console
To ensure that replication updates are sent immediately when a consumer or a supplier in a multi-master replication configuration comes back online after a period of time, you can perform these steps on the supplier server that holds the most recent version of the directory information:
- In the Directory Server Console, click the Configuration tab, expand the Replication folder and the database nodes until you select the replication agreement corresponding to the replica that you must update.
- Right click the replication agreement, and choose Send Updates Now from the drop-down list.
Forcing Replication Updates from the Command-Line
From the consumer that requires updating, you can run a script that prompts the supplier to send replication updates immediately. This script is shown in <Z_Online>Code Example 8-1.
You can copy this example and give it a meaningful name, such as replicate_now.sh. You must provide actual values for the variables listed in <Z_Online>Code Example 8-1.
You must run this script since it cannot be configured to run automatically as soon as the server, which was offline, comes back online again. |
If you intend to use this script, you must replace the variables with actual values in your replication environment.
If you want the update operation to occur over an SSL connection, you must modify the ldapmodify command in the script with the appropriate parameters and values. For more information on the ldapmodify command, refer to "Managing Entries from the Command-Line," on page 57, and Red Hat Directory Server Configuration, Command, and File Reference.
Replication over SSL
You can configure Directory Servers involved in replication so that all replication operations occur over an SSL connection.
To use replication over SSL, you must first do the following:
- Configure both your supplier and consumer servers to use SSL.
- Configure your consumer server to recognize your supplier server's certificate as the supplier DN. You do this only if you want to use SSL client authentication rather than simple authentication.
These procedures are described in <Z_Online>Chapter 11, "Managing SSL and SASL."
Replication configured over SSL with certificate-based authentication will fail in the following cases: |
When your servers are configured to use SSL, you can ensure replication operations occur over SSL connections by using the Replication Agreement Wizard, which enables you to set up a replication agreement between two Directory Servers. Keep in mind that once you create a replication agreement, you cannot change the connection type (SSL or nonSSL) defined in the agreement; this is because LDAP and LDAPS connections use different ports. To change the connection type, you must re-create the replication agreement.
Configuring Replication over SSL Using the Replication Agreement Wizard
- In the Directory Server Console of the supplier server, click the Configuration tab, expand the Replication folder, and select the database that you want to replicate.
- Right-click the database, and choose New Replication Agreement from the drop-down menu.
- Go through each step in the Replication Agreement Wizard until you reach the Source and Destination window.
- In the Connection section, check "Using Encrypted SSL Connection."
- Select "SSL Client Authentication" or "Simple Authentication."
Replication with Earlier Releases
This section provides information on how to optimize replication with earlier releases of Directory Server. This version of Directory Server can be involved in replication scenarios with earlier releases of Directory Server, providing the following conditions are met:
- Directory Server is defined as a consumer in the replication agreement.
- The legacy suppliers can be Directory Server 4.0, 4.1, and 4.1x.
The following restrictions apply:
- A legacy Directory Server and this version of Directory Server cannot update the same replica. However, this version of Directory Server can have different replicas, where one is supplied by a legacy Directory Server and the other is supplied by this version of Directory Server.
- This version of Directory Server cannot be a supplier for other replicas.
The main advantage of being able to use this version of Directory Server as a consumer of a legacy Directory Server is to ease the migration of a replicated environment. For more information on the steps to follow to migrate a replicated environment, refer to the Red Hat Directory Server Installation Guide.
Configuring Directory Server as a Consumer of a Legacy Directory Server
If you intend to use your Directory Server as a consumer of an earlier release of Directory Server, you must configure it as follows:
- In the Configuration tab, select the Replication node, and click the Legacy Consumer Settings tab in the right pane.
- Check the Enable Legacy Consumer checkbox.
- In the navigation tree, expand the Replication node, and select a replica that will receive updates from the legacy supplier.
- In the Replica Settings tab, select the Enable Replica and "Updatable by a 4.x Replica" checkboxes.
- Click Save.
- Repeat Step 7 and Step 8 for each read-only replica that will receive updates from a legacy supplier.
- To complete your legacy replication setup, you must now configure the legacy supplier to replicate to the Directory Server. For instructions on configuring a replication agreement on a 4.x Directory Server, refer to the documentation for your legacy Directory Server.
Using the Retro Changelog Plug-in
The retro changelog plug-in enables you to configure Directory Server to maintain a changelog that is compatible with the changelog implemented in Directory Server 4.0, 4.1, and 4.1x. Maintaining a retro changelog is essential in deployments where Directory Server coexists with the retired Netscape Meta Directory application. You might also need to maintain a retro changelog if you have directory clients that depend on a Directory Server 4.x style changelog.
To use the retro changelog plug-in, Directory Server must be configured as a supplier server in a single-master replication scenario.
When you have configured Directory Server to maintain a retro changelog, this changelog is stored in a separate database under a special suffix cn=changelog.
The retro changelog consists of a single level of entries. Each entry in the changelog has the object class changeLogEntry and can include the attributes listed in <Z_Online>Table 8-2.
This section contains information on the following retro changelog items:
- Enabling the Retro Changelog Plug-in
- Trimming the Retro Changelog
- Searching and Modifying the Retro Changelog
- Retro Changelog and the Access Control Policy
Enabling the Retro Changelog Plug-in
The retro changelog plug-in configuration information is stored in the cn=Retro Changelog Plugin,cn=plugins,cn=config entry in dse.ldif.
To enable the retro changelog plug-in from the command-line:
cn: Retro Changelog Plugin
changetype: modify
replace: nsslapd-pluginenabled
nsslapd-pluginenabled: on
The retro changelog is created in the directory tree under a special suffix, cn=changelog.
The procedure for enabling the retro changelog plug-in from Directory Server Console is the same as for all Directory Server plug-ins. For information, refer to "Enabling and Disabling Plug-ins from the Server Console," on page 516.
Trimming the Retro Changelog
The entries in the changelog can be automatically removed after a specified period of time. To configure the period of time after which entries are automatically deleted from the changelog, you must set the nsslapd-changelogmaxage configuration attribute in the cn=Retro Changelog Plugin,cn=plugins,cn=config entry.
The nsslapd-changelogmaxage attribute is a single-valued attribute. Its syntax is as follows:
nsslapd-changelogmaxage: Integer timeUnit
where Integer represents a number and timeUnit can be one of the following: s for seconds, m for minutes, h for hours, d for days, or w for weeks.
There should not be a space between the Integer and timeUnit variables. The space in the syntax above is intended to show that the attribute value is composed of two variable parts, not just one.
Example of nsslapd-changelogmaxage value:
nsslapd-changelogmaxage: 2d
Searching and Modifying the Retro Changelog
The changelog supports search operations. It is optimized for searches that include filters of the form:
(&(changeNumber>=X)(changeNumber<=Y))
As a general rule, you should not perform add or modify operations on the retro changelog entries, although you can delete entries to trim the size of the changelog. You will only need to perform a modify operation on the retro changelog is to modify the default access control policy.
Retro Changelog and the Access Control Policy
When the retro changelog is created, the following access control rules apply by default:
- Read, search, and compare rights are granted to all authenticated users (userdn=anyone, not to be confused with anonymous access where userdn=all) to the retro changelog top entry cn=changelog.
- Write and delete access are not granted except implicitly to the Directory Manager.
You should not grant read access to anonymous users because the changelog entries can contain modifications to sensitive information, such as passwords. Only authenticated applications and users should be allowed to access this information.
To modify the default access control policy which applies to the retro changelog, you can modify the aci attribute of the cn=changelog entry.
Monitoring Replication Status
You can monitor replication status using the Directory Server Console and Red Hat Administration Express. This section explains both these procedures:
- Monitoring Replication Status from the Directory Server Console
- Monitoring Replication Status from Administration Express
Monitoring Replication Status from the Directory Server Console
To view a summary of replication status via the Directory Server Console:
- Open the Directory Server Console.
- Select the Status tab, and then, in the left navigation tree, select Replication Status.
Monitoring Replication Status from Administration Express
Although the replication status report that you view via the Directory Server Console shows many details, it does not show the progress of the replication. Additionally, because one report is generated per agreement, you need to navigate among the status reports for different agreements.
The template-repl-monitor.pl script, which is explained in detail in the Red Hat Directory Server Configuration, Command, and File Reference, enables you to monitor replication status to a greater extent by providing these functionalities:
- Lists for each supplier replica on each Directory Server discovered, server URL or alias, replica ID, replica root, and maximum change sequence number (maxcsn).
- Lists corresponding to each supplier replica listed above and for each direct or indirect consumer replicas discovered, server URL or alias, replica root, replica type, connection type of the replication sessions, replication schedule, replication status, supplier maxcsn, and time lag between the consumer maxcsn and the supplier maxcsn.
- The time lag field uses different colors to indicate the degree of time lag. The threshold for each color is configurable.
- Displays the change sequence number (CSN) in human-readable format (instead of hex strings) in the MM/DD/YYYY HH:MI Seq# SubSeq# format, where Seq# and SubSeq# are omitted if they are zero.
- Shows the output/result in the HTML format. The script writes the output to an HTML file, which can be configured to refresh itself automatically; the refresh interval is also configurable.
The script is integrated into the Red Hat Administration Express, enabling you to view the replication status via an HTTP interface. (The Administration Express is an HTML-based version of Red Hat Console that provides quick access to servers running Administration Server.)
To view in-progress status of replication via the Administration Express interface:
- Prepare a configuration file following the guidelines provided in the "template-repl-monitor.pl (Monitor replication status)" section of the Red Hat Directory Server Configuration, Command, and File Reference.
- Open a web browser window.
- In the URL field, enter the Administration Server URL in this format:
http://hostname:admin_port
- Click Red Hat Administration Express, and, when prompted, log in.
- Select a supplier Directory Server instance, and click Replication Status.
- In the "Configuration file" field, type the path to the configuration file you created in Step 1, and click OK.
- Each table shows the status of the changes originated from a supplier replica.
- Table Header - The table header shows the replica ID of the supplier replica, the replica root, and the maximum Change State Number (CSN) on the supplier. The important thing is to make sure that each supplier LDAP server has its unique replica ID. Multiple replica roots on one LDAP server, however, could share the same replica ID.
- Table Row - Each row represents a direct or indirect consumer of the supplier (identified in the Table Header).
- Max CSN - It is the most recent CSN the consumer has replayed that was originated from the supplier (identified in the Table Header).
- Time Lag - It shows the time difference between the supplier and the consumer's max CSNs for the changes originated from the supplier (identified in the Table Header). A consumer is in sync with its supplier when its time lag is 0.
- Last Modify Time - It is roughly the time when the consumer's max CSN was replayed.
- Supplier - This column lists all the suppliers of the consumer.
- Sent/Skipped - Each supplier lists roughly how many changes originated from the supplier (identified in the Table Header) have been replayed or skipped by the consumer. The numbers are kept in suppliers' memory only. They will be cleared if the supplier is restarted.
- Update Status - The number is the status code, and the string is the implication of the status code. Watch this column for possible deadlock if all the suppliers complain that they cannot acquire busy replica. It is normal if one of the suppliers is doing an update while the others can't acquire busy replica.
Solving Common Replication Conflicts
Multi-master replication uses a loose consistency replication model. This means that the same entries can be changed on different servers. When replication occurs between the two servers, the conflicting changes need to be resolved. Mostly, resolution occurs automatically, based on the timestamp associated with the change on each server. The most recent change takes precedence.
However, there are some cases where change conflicts require manual intervention in order to reach a resolution. Entries that have a change conflict that cannot be resolved automatically by the replication process contain a conflict marker attribute nsds5ReplConflict. The nsds5ReplConflict attribute is an operational attribute, which makes it simple to search for entries that contain this attribute.
For example, you could use the following ldapsearch command:
ldapsearch -D adminDN -w password -b "dc=example,dc=com" "nsds5ReplConflict=*"
For performance reasons, if you find that you have many conflicting entries every day, you may want to index the nsds5ReplConflict attribute. For information on indexing, refer to <Z_Online>Chapter 10, "Managing Indexes."
This section contains the procedures for the following conflict resolution procedures:
Solving Naming Conflicts
When two entries are created with the same DN on different servers, the automatic conflict resolution procedure during replication renames the last entry created, including the entry's unique identifier in the DN. Every directory entry includes a unique identifier given by the operational attribute nsuniqueid. When a naming conflict occurs, this unique ID is appended to the non-unique DN.
For example, the entry uid=adamss,ou=people,dc=example,dc=com is created on server A at time t1 and on server B at time t2, where t2 is greater (or later) than t1. After replication, server A and server B both hold the following entries:
- uid=adamss,ou=people,dc=example,dc=com (created at time t1)
- nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com (created at time t2)
The second entry needs to be renamed in such a way that it has a unique DN. The renaming procedure depends on whether the naming attribute is single-valued or multi-valued. Each procedure is described below.
Renaming an Entry with a Multi-Valued Naming Attribute
To rename an entry that has a multi-valued naming attribute:
prompt> ldapmodify -D adminDN -w password >dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com >changetype: modrdn >newrdn: uid=NewValue >deleteoldrdn: 0
prompt> ldapmodify -D adminDN -w password >dn: uid=NewValue,dc=example,dc=com >changetype: modify >delete: uid >uid: adamss >- >delete: nsds5ReplConflict >-
For more information on the ldapmodify command, refer to "Managing Entries from the Command-Line," on page 57, and Red Hat Directory Server Configuration, Command, and File Reference.
The Console does not support editing of multi-valued RDNs. For example, assume you configured two servers in a multi-master mode, created an entry on each server with the same user ID, and changed the new entries' RDN to the nsuniqueid uid value. If you attempt to modify this entry from the Console, you get the following error: Changes cannot be saved for entries with multi-valued RDNs.
When you open the entry in the advanced mode, you will be able to see that the naming attribute has been set to nsuniqueid uid. However, you cannot change or correct the entry by changing the user ID and RDN values to something different. For example, if jdoe was the user ID and if you want to change it to jdoe1, you cannot do so from the Console. Instead, use the ldapmodify command:
ldapmodify: ldapmodify changetype: modify replace: uid uid: jdoe ldapmodify changetype: modrdn newrdn: uid=jdoe1 deleteoldrdn: 1
Renaming an Entry with a Single-Valued Naming Attribute
To rename an entry that has a single-valued naming attribute:
prompt> ldapmodify -D adminDN -w password >dn: nsuniqueid=66446001-1dd211b2+dc=pubs,dc=example,dc=com >changetype: modrdn >newrdn: cn=TempValue >deleteoldrdn: 0
prompt> ldapmodify -D adminDN -w password >dn: cn=TempValue,dc=example,dc=com >changetype: modify >delete: dc >dc: pubs >- >delete: nsds5ReplConflict >-
prompt> ldapmodify -D adminDN -w password >dn: cn=TempValue,dc=example,dc=com >changetype: modrdn >newrdn: dc=NewValue >deleteoldrdn: 1
For more information on the ldapmodify command, refer to "Managing Entries from the Command-Line," on page 57, and Red Hat Directory Server Configuration, Command, and File Reference.
Solving Orphan Entry Conflicts
When a delete operation is replicated and the consumer server finds that the entry to be deleted has child entries, the conflict resolution procedure creates a glue entry to avoid having orphaned entries in the directory.
In the same way, when an add operation is replicated and the consumer server cannot find the parent entry, the conflict resolution procedure creates a glue entry representing the parent so that the new entry is not an orphan entry.
Glue entries are temporary entries that include the object classes glue and extensibleObject. Glue entries can be created in several ways:
- If the conflict resolution procedure finds a deleted entry with a matching unique identifier, the glue entry is a resurrection of that entry, with the addition of the glue object class and the nsds5ReplConflict attribute.
- In such cases, either you can modify the glue entry to remove the glue object class and the nsds5ReplConflict attribute to keep the entry as a normal entry or you can delete the glue entry and its child entries.
- In such cases, you must modify the entry to turn it into a meaningful entry or delete it and all of its child entries.
Solving Potential Interoperability Problems
For reasons of interoperability with applications that rely on attribute uniqueness, such as a mail server, you might need to restrict access to the entries which contain the nsds5ReplConflict attribute. If you do not restrict access to these entries, then the applications requiring one attribute only will pick up both the original entry and the conflict resolution entry containing the nsds5ReplConflict, and operations will fail.
To restrict access, you need to modify the default ACI that grants anonymous read access, using the following command:
ldapmodify -h hostname -D "cn=Directory Manager" -w password > dn: dc=example,dc=com > changetype: modify > delete: aci > aci: (target ="ldap:///dc=example,dc=com")(targetattr !="userPassword")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare)(userdn = "ldap:///anyone");) > - > add: aci > aci: (target="ldap:///dc=example,dc=com")(targetattr!="userPassword" ) (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn="ldap:///anyone");) > -
The new ACI filters out all entries that contain the nsds5ReplConflict attribute from search results.
For more information on the ldapmodify command, refer to "Managing Entries from the Command-Line," on page 57, and Red Hat Directory Server Configuration, Command, and File Reference.
Troubleshooting Replication-Related Problems
This section covers the following:
Interpreting Error Messages and Symptoms
This section lists some error messages, explains possible causes, and offers remedies.
It is possible to get more debugging information for replication by setting the error log level to 8192, which is replication debugging. For details on error log level, check the Red Hat Directory Server Configuration, Command, and File Reference.
To change the error log level to 8192, run the following ldapmodify command:
dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 8192
Because log level is additive, running the above command will result in excessive messages in the error log. So, use it judiciously.
To turn off replication debugging log, set the same attribute to 0.
agmt=%s (%s:%d) Replica has a different generation ID than the local data
Warning: data for replica %s was reloaded, and it no longer matches the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers, in which case the consumers should be reinitialized.
agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB rc=%d). The consumer may need to be reinitialized.
agmt=%s(%s:%d): Warning: Unable to send endReplication extended operation (%s)
changetype: modify
add: nsslapd-changelogmaxage
nsslapd-changelogmaxage: 1d
- With changelog purge turned on, a purge thread that wakes up every five minutes will remove a change if its age is greater than the value of nsslapd-changelogmaxage and if it has been replayed to all the direct consumers of this supplier (supplier or hub).
- If it appears that the changelog is not purged when the purge threshold is reached, check the maximum time lag from the replication monitor among all the consumers. Irrespective of what the purge threshold is, no change will be purged before it is replayed by all the consumers.
The Replication Monitor is not responding. (For information on Replication Monitor, see "Monitoring Replication Status," on page 366.)
In the Replication Monitor, some consumers show just the header of the table. (For information on Replication Monitor, see "Monitoring Replication Status," on page 366.)
Useful Tools
The template-cl-dump.pl script, which is explained in detail in the Red Hat Directory Server Configuration, Command, and File Reference, enables you to troubleshoot replication-related problems. Depending on the usage options, the script can selectively dump a particular replica: