Replication

You can share between several directory servers the load of processing requests generated by directory service clients for the same information. This is done by defining a replica, or slave server to provide an alternative access point to the directory service for clients. A master naming context can have more than one replica naming context. FIGURE 1-10 shows a master server with two replica servers. Replication is the process by which changes in the master data store are propagated to all the replica naming contexts. You can replicate an entire naming context, a subtree, or a particular entry. You can replicate the entire content of an entry or you can specify a subset of attributes to be replicated.

FIGURE  1-10 Master and Replica Servers

Using replication has the following advantages:

It reduces the load on the master server by diverting some traffic to other servers.

You can store copies of data where it is mostly frequently used, thus reducing network traffic.

You can store many copies of the data, but the data is maintained from a central location.

You need only replicate the data that is required by clients of the replica server, if you know the requirements of those clients specifically enough. You may be able to tailor a replica exactly to the needs of a specific client. By reducing the number of entries replicated, you reduce the network traffic caused by replication updates.

You could maintain a "public" replica server containing information that is not confidential, allowing greater access to this information than you usually allow for other servers. For example, you could create a server containing the email addresses for the sales and support staff who deal with current products but not the research staff working on future products, and make it available to the sales staff of a partner company.

---

Note - You could provide the same partial view of directory information with appropriate access controls. However, using a partial replica on a dedicated machine ensures that you are not providing access to your entire network. For extra security, you could connect the replica server to your network only while the replication update is in progress.

---

The costs of using replication are:

Additional network traffic caused by replication of data. However, though there may be an overall increase in traffic, more of the traffic will be local, so you can avoid known network bottlenecks for inquiry traffic. Also, you can time the replication updates for when the network is least busy.

Information retrieved from replicas may be out of date if replication has not happened since an update, so certain applications may always need to query the master data store.

You cannot modify a replica. All updates must be performed on the master copy of an entry.

How Replication Works

Information from a master naming context is propagated to a replica by the slurpd daemon. The slurpd daemon can run permanently, so that updates to directory information are propagated immediately, or you can define a synchronization schedule. You can override the schedule at any time and trigger an immediate synchronization. This is useful if you change a large number of entries and do not want to wait for the next scheduled synchronization.

The slurpd daemon uses the LDAP protocol to update a replica naming context. A master naming context for which a replica is defined maintains a replication log. Each time the master naming context is updated, the transaction is recorded in the replication log. When the slurpd daemon next runs, it reads the replication log and sends the change to the slapd server that holds the replica naming context. The slapd server handles update requests from slurpd in the same way that it handles all requests, using the information supplied in the bind request to set the access level granted to slurpd requests. To guarantee that all replication updates are completed, slurpd must bind with the DN defined when the replica naming context was configured. If a different DN is used, write access for all entries may not be granted.

A replica data store always has a referral pointing to the master data store. If a replica server receives a request to modify an entry, it returns a referral to the client, indicating the master server to be contacted. In some cases, the client software handles the referral automatically and the user need not resubmit the query. Once the modification has been made in the master naming context, the change is sent to the replica naming context the next time the slurpd daemon runs.

Example: Replication in the XYZ Corporation

FIGURE 1-8 and FIGURE 1-9 show the naming contexts in the XYZ Corporation DIT and the servers that store them. In addition, the network management team decide to establish several replica naming contexts:

All servers will contain a replica of l=Boston, o=XYZ, c=US for fast access to entries concerning the headquarters of the corporation. Only ussales, eursales, and rowsales get their replicas directly from the boston server. The other servers get a replica of the replica from the server that is closest in the network.

A second server, eursale2, will hold a complete replica of ou=Euro-Sales, o=XYZ, c=US to share the load on the existing eursales server.

Each of the servers at the distribution centers will hold complete or partial replicas of the other distribution center naming contexts. For example, the atlanta server will hold a complete replica of ou=London-Dist, o=XYZ, c=US and a partial replica of l=Tokyo, o=XYZ, c=US containing the information about the distribution center but not about the sales office.

TABLE 1-6 shows the replication strategy for each server in the XYZ Corporation directory service.

For details of how to implement this replication strategy for the XYZ Corporation, see "Configuring Replication for XYZ Corporation" on page 200.