Setting Up a Replication Strategy

To set up a replication strategy, you need to identify the number of locations where the same information is present, determine which location will hold the master copy, and define the most efficient replication process between servers.

Simple and Cascading Replication

If you have two locations that hold the same information, you will have a simple replication with one master and one slave. If you have three or more locations that hold the same information, you can have a simple replication with one master and two or more slaves, or a cascading replication.

In a cascading replication, there are several levels of information replication: a replica copy on a slave server is in turn replicated to another slave. For information that is replicated in many locations, a cascading replication has the advantage of reducing the network traffic originating from the master server by sharing the load with the first level of slave servers.

Replication Methods

Sun Directory Services replication is based on the LDAP protocol. However, when the NIS service is enabled on a Sun Directory Services server, NIS replication can take place between this server and legacy NIS servers.

The NIS replication feature of Sun Directory Services offers a smooth transition from a classic NIS naming service to an integrated naming and directory service.

LDAP replication has the following advantages over NIS replication:

• Partial replication is possible: you can choose the part of the DIT that you want to replicate, and you can also replicate just the changed attributes of modified entries

• Better scalability: NIS replication is likely to fail if the number of entries replicated is in excess of 50,000.

Therefore, when the Sun Directory Services product is installed on several servers used as NIS servers, NIS replication should be disabled in favor of LDAP replication. For details, refer to "Configuring the NIS Service".

There are two replication modes for propagating changes between master servers and slave servers:

• Master-based replication: the master server owns the synchronization schedule and pushes modifications to its slaves

• Client-based replication: the slave server owns the synchronization schedule, and pulls modifications from the master server

---

Caution -

If you have both LDAP v2 and LDAP v3 servers in your environment, you may lose LDAP v3 specific information when replicating from an LDAP v3 server to an LDAP v2 server. For example, if replicated information makes use of language tags in attributes, all replication targets must support LDAP v3. Refer to the product release notes for details of migration from Sun Directory Services 1.0 to Sun Directory Services 3.1.

---

Example: Replication in the XYZ Corporation

Table 3-1 shows that some of the naming contexts in the XYZ Corporation are held on several servers in order to provide faster access and to reduce the connection costs by keeping information local.

One server holds the master copy, the others are replicas.

Table 3-2 shows the replication strategy for each naming context in the XYZ Corporation directory service.

Table 3-2 Replication Strategy for the XYZ Corporation

Naming Context	Master Server	Slave Server
ou=People, ou=XYZ, c=US	boston	london
ou=Services, ou=XYZ, c=US	boston	london
ou=HR, ou=XYZ, c=US	boston	london
l=Boston, ou=XYZ, c=US	boston
l=New-York, ou=XYZ, c=US	newyork
ou=US-RD, ou=XYZ, c=US	newyork	paris
ou=Sales-Mktg, ou=XYZ, c=US	newyork	paris
l=London, ou=XYZ, c=US	london
l=Paris, ou=XYZ, c=US	paris
ou=Eur-RD, ou=XYZ, c=US	paris	newyork

The replication method used to replicate changes between master servers and slave servers is LDAP.