 |
Administrator's
Guide Netscape Directory Server |
| Previous |
Contents |
Index |
DocHome | Next |
Replication is the mechanism by which directory data is automatically copied from one Netscape 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:
For conceptual information on how you can use replication in your directory deployment, see the Netscape Directory Server Deployment Guide.
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:
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.
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 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.
Every supplier server maintains a change log. A change log 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 change log.
In Directory Server, the format of the change log has changed. It is now only intended for internal use by the server. If you have applications that need to read the change log, you need to use the Retro Change Log Plug-in for backward compatibility. For more information, refer to Using the Retro Change Log Plug-in.
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 Netscape 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.
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:
For more information on creating the Replication Manager entry, refer to Creating the Supplier Bind DN Entry.
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 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:
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.
|
|
|
|
Whatever replication scenario you choose to implement, remember to consider schema replication. For details, see Netscape Directory Server Deployment Guide. To avoid conflict resolution loops, the Referential Integrity Plug-in should only be enabled on one supplier replica in a multi-master replication environment. The plug-in is off by default.
|
|
|
|
|
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 change log 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. Figure 8-1 shows an example of 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.
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 change log 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.
Figure 8-2 shows an example of multi-master replication scenario with two supplier servers and two consumer servers.
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.
Multi-master configurations have the following advantages:
|
|
|
|
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.
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 change log. 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.
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.
For information on setting up cascading
replication, refer to Configuring
Cascading Replication.
|
|
|
|
You can combine multi-master and cascading replication. For example, in the multi-master scenario illustrated in Figure 8-2, server C and server D could be hub suppliers that would replicate to any number of consumer servers.
|
|
|
|
|
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:
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:
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.
When you configure a replica as a consumer, you must use the DN of this entry to define the supplier bind DN.
On any server that holds the master copy of a replica, you must specify supplier settings.
To configure supplier settings:
For each read-write replica on the supplier server, you must specify the appropriate replication settings.
To configure a read-write replica:
For each read-only replica on the consumer server, you must specify the appropriate replication settings.
In a cascading replication environment, configure the hub supplier as follows:
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:
To create a replication agreement:
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 Figure 8-1 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:
|
|
|
|
This entry must not be part of the replicated database.
|
|
|
|
|
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.
When you have finished, the replication agreement is set up.
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.
To set up multi-master replication such as the configuration shown in Figure 8-2, 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:
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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
In the case of multi-master replication, you should initialize replicas in the following order:
For information on initializing replicas, refer to Initializing Consumers.
Directory Server supports 4-way multi-master replication. To set up multi-master replication such as the configuration shown in Figure 8-3, 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:
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
When you have
finished, the replication
agreement is set up.
|
|
|
|
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 and Initializing Consumers.
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.
In the case of multi-master replication, you
should initialize replicas in the following order:
For information on initializing replicas, refer to Initializing Consumers.
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 change log. 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 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.
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 Figure 8-4, 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:
To configure the read-only replica in a consumer server:
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.
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.
|
|
|
|
|
Perform these steps on the supplier server that holds the original copy of the database:
In the case of cascading replication, you should initialize
replicas in the following order:
For information on initializing replicas, refer to Initializing Consumers.
To make a read-only server writable, follow this procedure:
The change log 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 change log 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 change log, you can initialize your consumers and begin the replication process afresh. To delete the change log, you can either remove it or move it to a new location.
This section contains the information for the following procedures:
You can remove the change log using the Directory Server Console. To remove the change log from the supplier server:
|
|
|
|
If you remove the change log, you will need to reinitialize your consumer servers.
|
|
|
|
|
To delete the change log while the server is still running and continuing to log changes, you simply move the change log to a new location. By moving the change log, a new change log is created in the directory you specify, and the old change log is deleted. If you change the location of the change log, it is as if you are reinitializing it, which in turn requires consumer reinitialization.
For example, you could move the change log from the default location of
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:
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 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, for more information.
To initialize or reinitialize a consumer online:
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.
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:
To initialize or reinitialize a server manually:
You can convert the replica to LDIF using one of the following three procedures:
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.
If you use the ldif2db
script, remember to bind using the supplier bind DN configured on the
consumer server.
|
|
|
|
If you use the ldif2db.pl script, the LDIF file import operation does not require a server restart. For more information on command-line scripts, see Netscape Directory Server Configuration, Command, and File Reference.
|
|
|
|
|
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.
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:
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 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 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.
Table 8-1
Replicate_Now Variables
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 and Netscape Directory Server Configuration, Command, and File Reference.
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:
These procedures are described in chapter 11, "Managing SSL and SASL."
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.
|
|
|
|
If you have enabled attribute encryption, you must use a secure connection for replication.
|
|
|
|
|
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:
The following restrictions apply:
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 Netscape Directory Server Deployment Guide.
If you intend to use your Directory Server as a consumer of an earlier release of Directory Server, you must configure it as follows:
The retro change log plug-in enables you to configure Directory Server to maintain a change log that is compatible with the change log implemented in Directory Server 4.0, 4.1, and 4.1x. Maintaining a retro change log is essential in deployments where Directory Server coexists with Netscape Meta Directory. You might also need to maintain a retro change log if you have directory clients that depend on a Directory Server 4.x style change log.
To use the retro change log 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 change log, this change log is stored in a separate database under a special suffix cn=changelog.
The retro change log consists of a single
level of entries. Each entry in the change log has the object class
changeLogEntry and can include the attributes listed in Table 8-2.
Table
8-2 Attributes of a Retro Changle Log Entry
This section contains information on the following retro change log items:
The retro change log plug-in configuration information is stored in the cn=Retro Changelog Plugin,cn=plugins,cn=config entry in dse.ldif.
To enable the retro change log plug-in from the command-line:
The retro change log is created in the directory tree under a special suffix, cn=changelog.
The procedure for enabling the retro change log 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.
The entries in the change log can be automatically removed after a specified period of time. To configure the period of time after which entries are automatically deleted from the change log, 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.
The change log 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 change log entries, although you can delete entries to trim the size of the change log. You will only need to perform a modify operation on the retro change log is to modify the default access control policy.
When the retro change log is created, the following access control rules apply by default:
You should not grant read access to anonymous users because the change log 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 change log, you can modify the aci attribute of the cn=changelog entry.
You can monitor replication status using the Directory Server Console and Netscape Administration Express. This section explains both these procedures:
To view a summary of replication status via the Directory Server Console:
In the right pane, a table appears that contains information about each of the replication agreements configured for this server.
The status information displayed is described in Directory Server Console - Replication Status.
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 Netscape Directory Server Configuration, Command, and File Reference, enables you to monitor replication status to a greater extent by providing these functionalities:
The script is integrated into the Netscape Administration Express, enabling you to view the replication status via an HTTP interface. (The Administration Express is an HTML-based version of Netscape Console that provides quick access to servers running Administration Server.)
To view in-progress status of replication via the Administration Express interface:
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 chapter 10, "Managing Indexes."
This section contains the procedures for the following conflict resolution procedures:
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:
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.
To rename an entry that has a multi-valued naming attribute:
|
|
|
|
You cannot delete the unique identifier attribute nsuniqueid.
|
|
|
|
|
For more information
on the
ldapmodify command, refer to Managing Entries from the Command-Line and Netscape
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
To rename an entry that has a single-valued naming attribute:
|
|
|
|
You cannot delete the unique identifier attribute nsuniqueid.
|
|
|
|
|
For more information on the ldapmodify command, refer to Managing Entries from the Command-Line and Netscape Directory Server Configuration, Command, and File Reference.
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:
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 and Netscape Directory Server Configuration, Command, and File Reference.
This section covers the following:
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 Netscape 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.
Reason: The consumer specified at the beginning of this message has not been (successfully) initialized yet, or it was initialized from a different root supplier.
Impact: The local supplier will not replicate any data to the consumer.
Remedy: Ignore this message if it occurs before the consumer is initialized. Otherwise, reinitialize the consumer if the message is persistent. In a multi-master environment, all the servers should be initialized only once from a root supplier, directly or indirectly. For example, M1 initializes M2 and M4, M2 then initializes M3, and so on. The important thing to note is that M2 must not start initializing M3 until M2's own initialization is done (check the total update status from the M1's Console or M1 or M2's error log). Also, M2 should not initialize M1 back.
Reason: This message may appear only when a supplier is restarted. It indicates that the supplier was unable to write the changelog or did not flush out its RUV at its last shutdown. The former is usually because of a disk-space problem, and the latter because a server crashed or was ungracefully shut down.
Impact: The server will not be able to send the changes to a consumer if the consumer's maxcsn no longer exists in the server's changelog.
Remedy: Check the disk space and the possible core file (under the server's logs directory on UNIX systems). If this is a single-master replication, reinitialize the consumers. Otherwise, if the server later complains that it can't locate some CSN for a consumer, see if the consumer can get the CSN from other suppliers. If not, reinitialize the consumer.
Reason: Most likely the change log was recreated because of the disk is full or the server ungracefully shutdown.
Impact: The local server will not be able to send any more change to that consumer until the consumer is reinitialized or gets the CSN from other suppliers.
Remedy: If this is a single-master replication, reinitialize the consumers. Otherwise, see if the consumer can get the CSN from other suppliers. If not, reinitialize the consumer.
Reason: The system clocks on the host machines are way out of sync.
Impact: The system clock is used to generate a part of the CSN. In order to reflect the change sequence among multiple suppliers, suppliers would forward-adjust their local clocks based on the remote clocks of the other suppliers. Because the adjustment is limited to a certain amount, any difference that exceeds the permitted limit will cause the replication session to be aborted.
Remedy: Synchronize the system clocks on the Directory Server host machines. If applicable, run the network time protocol (ntp) daemon on those hosts.
Reason: The consumer is not responding.
Impact: If the consumer recovers without being restarted, there is a chance that the replica on the consumer will be locked forever if it did not receive the release lock message from the supplier.
Remedy: Watch if the consumer can receive any new change from any of its suppliers, or start the replication monitor, and see if all the suppliers of this consumer warn that the replica is busy. If the replica appears to be locked forever and no supplier can get in, restart the consumer.
Reason: Either change log purge is turned off, which is the default setting, or change log purge is turned on, but some consumers are way behind the supplier.
Remedy: By default change log purge is turned off. To turn it on from the command-line, run ldapmodify as follows:
dn:
cn=changelog5,cn=config
changetype:
modify
add:
nsslapd-changelogmaxage
nsslapd-changelogmaxage:
1d
where 1d means 1 day. Other valid time units are s(econds), m(inutes), h(ours), and w(eeks). A value of 0 turns off the purge.
With change log 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 change log 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.
Reason: The SSL port is specified in some replication agreement, but the certificate database is not specified or not accessible by the Replication Monitor. If there is no SSL port problem, one of the servers in the replication topology might hang.
Remedy: Map the SSL port to a non-SSL port in the configuration file of the Replication Monitor. For example, if 636 is the SSL port and 389 is the non-SSL port, add the following line in the [connection] section:
The template-cl-dump.pl script, which is explained in detail in the Netscape 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:
| Previous |
Contents |
Index |
DocHome | Next |