This section covers the following topics:
For information about planning your replication, see the Sun Java System Directory Server Enterprise Edition 6.1 Deployment Planning Guide.
In multi-master replication, replicas of the same data exist on more than one server. For information about multi-master replication, see the following sections:
In a multi-master configuration, data is updated on multiple masters. Each master maintains a change log, and the changes made on each master are replicated to the other servers. Each master plays the role of supplier and consumer.
Multi-master replication can cause synchronization conflicts. Conflicts are usually resolved automatically by using the timestamp associated with each change, where the most recent change takes precedence. Some rare conflicts must be resolved manually. For more information, see Solving Common Replication Conflicts in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.
Each supplier in a multi-master environment must have a replication agreement. The following figure shows two master servers and their replication agreements.
In the preceding figure, Master A and Master B have a master replica of the same data. Each master has a replication agreement that specifies the replication flow. Master A acts as a master in the scope of Replication Agreement 1, and as a consumer in the scope of Replication Agreement 2.
Multi-master replication can be used for the following tasks:
To replicate updates by using the replica ID.
Updates by using the replica ID make it possible for a consumer to be updated by multiple suppliers at the same time, provided that the updates originate from different replica IDs.
To enable or disable a replication agreement.
Replication agreements can be configured but left disabled, then enabled rapidly when required. This feature provides flexibility in replication configuration. This can be done whether you use multiple masters or not.
Directory Server supports multi-master replication over WANs, enabling multi-master replication configurations across geographical boundaries in international, multiple data center deployments.
The replication protocol provides full asynchronous support, window and grouping mechanisms, and support for compression. These features render multi-master replication over WAN a viable deployment possibility.
In a multi-master replication over WAN configuration, all instances of Directory Server separated by a WAN must support multi-master replication over WANs.
The group mechanism and window mechanism can be used to group changes rather than send them individually. The group mechanism and window mechanism can also be used to specify a number of requests that can be sent to the consumer without the supplier waiting for an acknowledgement from the consumer.
For information about how to adjust the group size and window size, see Configuring Network Parameters in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.
Replication compression helps to streamline replication flow and avoid bottlenecks caused by limited bandwidth.
In a fully meshed multi-master topology, each master is connected to each of the other masters. A fully meshed topology provides high availability and guaranteed data integrity. The following figure shows a fully meshed, four-way, multi-master replication topology with some consumers.
In Figure 4–2, the suffix is held on four masters to ensure that it is always available for modification requests. Each master maintains its own change log. When one of the masters processes a modification request from a client, it records the operation in its change log. The master then sends the replication update to the other masters, and in turn to the other consumers. Each master also stores a Replication Manager entry used to authenticate the other masters when they bind to send replication updates.
Each consumer stores one or more entries that correspond to the Replication Manager entries. The consumers use the entries to authenticate the masters when they bind to send replication updates. It is possible for each consumer to have just one Replication Manager entry that enables all masters to use the same Replication Manager entry for authentication. By default, the consumers have referrals set up for all masters in the topology. When consumers receive modification requests from the clients, they send the referrals to back to the client. For more information about referrals, see Referrals and Replication.
Figure 4–3 presents a detailed view of the replication agreements, change logs, and Replication Manager entries that must be set up on Master A.Figure 4–4 provides the same detailed view for Consumer E.
Master A requires the following:
A master replica
A change log
Replication Manager entries for Masters B, C, and D, unless you use the same Replication Manager entry on each replica
Replication agreements for Masters B, C, and D, and for Consumers E, and F
Consumer E requires the following:
A consumer replica
Replication Manager entries to authenticate Masters A, and B when they bind to send replication updates
In a cascading replication configuration, a server acting as a hub receives updates from a server acting as a supplier. The hub replays those updates to consumers. The following figure illustrates a cascading replication configuration.
Cascading replication is useful in the following scenarios:
When there are a lot of consumers.
Because the masters in a replication topology handle all update traffic, it could put them under a heavy load to support replication traffic to the consumers. You can off-load replication traffic to several hubs that can each service replication updates to a subset of the consumers.
To reduce connection costs by using a local hub in geographically distributed environments.
The following figure shows cascading replication to a large number of consumers.
In Figure 4–6, hubs 1 and 2 relay replication updates to consumers 1 through 10, leaving the master replicas with more resources to process directory updates.
The masters and the hubs maintain a change log. However, only the masters can process directory modification requests from clients. The hubs contains a Replication Manager entry for each master that sends updates to them. Consumers 1 through 10 contain Replication Manager entries for hubs 1 and 2.
The consumers and hubs can process search requests received from clients, but cannot process modification requests. The consumers and hubs refer modification requests to the masters.
In previous versions of Directory Server, updates were replicated in chronological order. In this version of the product, updates can be prioritized for replication. Priority is a boolean feature, it is on or off. There are no levels of priority. In a queue of updates waiting to be replicated, updates with priority are replicated before updates without priority.
Priority rules are configured with the following replication priority rule properties:
The identity of the client, bind-dn.
The type of update, op-tyupe.
The entry or subtree that was updated, base-dn.
The attributes changed by the update, att.
For information about these properties, see repl-priority(5dsconf).
When the master replicates an update to one or more hubs or consumer replicas, the priority of the update is the same across all of the hubs and consumer replicas. If one parameter is configured in a priority rule for prioritized replication, all updates that match that parameter are prioritized for replication. If two or more parameters are configured in a priority rule for prioritized replication, all updates that match all parameters are prioritized for replication.
In the following scenario, it is possible that a master replica attempts to replicate an update to an entry before it has replicated the addition of the entry:
The entry is added on the master replica and then updated on the master replica
The update operation has replication priority but the add operation does not have replication priority
In this scenario, the update operation cannot be replicated until the add operation is replicated. The update waits for its chronological turn, after the add operation, to be replicated.
Fractional replication can be used to replicate a subset of the attributes of all entries in a suffix or sub-suffix. Fractional replication can be configured, per agreement, to include attributes in the replication or to exclude attributes from the replication. Usually, fractional replication is configured to exclude attributes. The interdependency between features and attributes make managing a list of included attributes difficult.
Fractional replication can be used for the following purposes:
To filter content for synchronization between intranet and extranet servers
To reduce replication costs when a deployment requires only certain attributes to be available everywhere
Fractional replication is configured with the replication agreement properties repl-fractional-include-attr and repl-fractional-exclude-attr attributes. For information about these properties, see repl-agmt(5dsconf). For information about how to configure fractional replication, see Fractional Replication in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.
Fractional replication is not backward compatible with versions of Directory Server prior to Directory Server 5.2. If you are using fractional replication, ensure that no other instances of Directory Server are prior to Directory Server 5.2.