This chapter explains how replication works in Sun Directory Services, and explains how to configure replication for your directory servers using the Admin Console.
Information from a master naming context is propagated to a replica by the dspushd daemon. This information can also be pulled from the master server by the dspulld daemon running on the replica server. The dspushd and dspulld daemons use 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 dspushd daemon next runs, it reads the replication log and sends the change to the server that holds the replica naming context. The dsservd server handles update requests from dspushd in the same way that it handles all requests, using the information supplied in the bind request to set the access level granted to dspushd requests. To guarantee that all replication updates are completed, dspushd 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.
If replication is managed by the slave server, the dspulld daemon compares the master and the replica naming contexts, and performs the necessary updates on the replica.
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. Once the modification has been made in the master naming context, the change is sent to the replica naming context the next time the dspushd daemon runs.
Any naming context held in the data store, including replica naming contexts, can be replicated to another server.
Before you start configuring replication on master servers and slave servers, you must make the following decisions:
What information you want to replicate
Which server will hold the master copy
Which servers will hold replicas
Will the master server push updates to all slaves, or will replica servers individually pull updates from the master
In defining the information you want to replicate, you specify:
The entries you want to replicate
The attributes you want to replicate
To select the entries to replicate, you can:
Provide the DN of a subtree: all the entries in the subtree are replicated
Specify an individual entry (object)
Specify a filter
To select the attributes to replicate, you can:
Specify all attributes
Include or exclude certain attributes from the replication
You can also define a replication synchronization schedule. This schedule determines when all updates are sent to replicas. There are three types of synchronization:
Immediate, which means that the replication daemon, dspushd, runs permanently and sends updates to the replica immediately when modifications are made in the master.
Delayed, which means that modifications are logged until the next time dspushd runs. If you select Delayed synchronization, specify a schedule for dspushd.
Disabled, which means that modifications are not automatically sent to the replica.
You can use the Send updates now control in the Admin Console to send any outstanding modification immediately to a replica. Setting the synchronization type to Disabled and using the Send updates now control to initiate replication updates manually can be useful where the update traffic is unpredictable, or where the remote server is connected by a dial-up line.
On the master server you must:
Declare all the replica servers -- see "To Create Replicas"
Optionally, set up a synchronization schedule -- see "To Set Up a Replication Synchronization Schedule for a Master Server"
In the Create Data Store window or the Modify Data Store window, choose Replica from the Create menu.
The Add Replica window is displayed.
Specify the type of replica (subtree or object).
In the Subtree/Entry field, specify the distinguished name of the subtree or object to be replicated.
To create a replica of the whole data store, specify the DN of the naming context used to identify the data store.
Select the attributes to be replicated.
You can specify that all attributes are replicated, or you can exclude or include certain attributes. If you choose Exclude or Include from the Attributes pop-up menu, specify the particular attributes you want to exclude from or include in the replica.
Specify the following parameters for the target:
The name of the target host (replica server) where the replica will be stored
Specify the port of the dsservd server on the replica server to be used by the replication daemon, dspushd
The distinguished name and password that the master will supply when requesting authentication
The Bind method, simple, SASL with CRAM-MD5, or SASL with the EXTERNAL mechanism
The security mode, insecure, TLS, or SSL, and the SSL key package if you select TLS or SSL as the security mode
For example, Figure 9-1 shows an example of replicating the naming context ou=People, o=XYZ, c=US from the boston server (not shown) to the london slave server.
Click OK to save the replica definition and exit from the Add replica window.
Information concerning the replica is added to the list in the Replicas section of the Create Data Store or Modify Data Store window.
Click OK to dismiss the data store window.
In the Data Store section of the Admin Console main window, click on the folder icon for the data store to check that the replica you have just created is listed under the Replicas folder.
For example, Figure 9-2 shows the naming contexts held on the boston server, and the replica defined for the london slave server.
From the Send Updates to Replica menu button select Delayed.
A Day menu button and Time menu button are displayed.
Select the day and time at which you want replication to occur periodically.
Click Apply in the Admin Console main window to save your changes.
In the Data Store section of the Admin Console main window, highlight the replica that you want to synchronize with the master, and click the Send updates now button.
On your slave servers, you must:
Create the naming context for the replica on the server, as described in "To Create a Data Store", making sure that you select Slave mode
Optionally, configure pull replication, if you have not configured the master to push updates automatically to replicas
Optionally, set up a synchronization schedule -- see "To Start Replication At Any Time from a Slave Server"
You must ensure that the schema supported by the slave server is compatible with the entries that you want to replicate. If entries to replicate depend on changes made to the master server schema, you must make the same changes to the slave server schema. It is not sufficient to copy the subschema object class from the master server schema to the slave server schema.
This procedure is described as part of the procedure for creating a data store in "To Create a Data Store". If the replica naming context exists, double-click on it in the Data Store section of the Admin Console.
In the Add Naming Context Window or the Modify Naming Context Window, set the Configure Pull Replication button to Yes.
This displays additional replication parameter fields.
Select the attributes to replicate.
If you select Include attributes or Exclude attributes, you must specify a list of attributes to include in or exclude from the replication.
Specify the following parameters for the master server:
The distinguished name and password that the slave server will supply when requesting authentication
The LDAP timeout on the bind request
The Bind method, security mode, and SSL key package if you select SSL as the security mode
Click OK to save your changes and dismiss the Add Naming Context window.
In the Data Store section of the Admin Console main window, an extra set of controls is displayed. These controls enable you to set up a synchronization schedule on the slave server, and to start replication at any time from the slave.
From the Request Updates from Master menu button select Enabled.
A Day menu button and Time menu button are displayed.
Select the day and time at which you want replication to occur periodically.
Click Apply in the Admin Console main window to save your changes.
In the Data Store section of the Admin Console main window, highlight the replica that you want to synchronize with the master, and click the Request updates now button.
After you have configured a replica naming context, the master and replica data stores must be in the same state, so that the replica can receive replication updates from the master. If the master data store already contains entries, the Admin Console displays a dialog box giving you the option of populating the replica. Use this facility to populate the replica automatically with the entries that the master contains.
Although you can start the replication process from the Admin Console, the Admin Console does not control the process and does not display error messages. You need to check the replication log files, dspush.log and dspull.log, to ensure that the replication process has completed successfully.