Chapter 8. Managing Replication
8.1. Replication Overview
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:
8.1.1. What Directory Units Are Replicated
The smallest unit of of the directory which can be replicated is a database. This means that one can replicate an entire database but not a subtree within a database. Therefore, when creating the directory tree, consider any replication plans as part of determining how to distribute information.
Replication also requires that one database correspond to one suffix. This means that a suffix (or namespace) that is distributed over two or more databases using custom distribution logic cannot be replicated. For more information on this topic, see
Section 3.2, “Creating and Maintaining Databases”.
8.1.2. Read-Write and Read-Only Replicas
A database that participates in replication is called 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 services read, search, and compare requests, but refers all update operations to read-write replicas. A server can hold any number of read-only or read-write replicas.
8.1.3. Suppliers and Consumers
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, with two exceptions:
Replication is always initiated by the supplier server, never by the consumer (supplier-initiated replication). Supplier-initiated replication allows a supplier server to be configured to push data to multiple consumer servers.
Every supplier server maintains a changelog, a record of all changes that a supplier or hub needs to send to its consumers. A changelog is a special kind of database 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 changelog.
8.1.5. Replication Identity
When replication occurs between two servers, the replication process uses a special entry, called the replication manager entry, to identify replication protocol exchanges and to control access to the directory data. The replication manager entry, or any entry used during replication, must meet the following criteria:
It is created on the consumer server (or hub) and not on the supplier server.
Create this entry on every server that receives updates from another server, meaning on every hub or dedicated consumer.
When a replica is configured as a consumer or hub (a replica which receives updates from another server), this entry must be specified as the one authorized to perform replication updates.
The replication agreement is created on the supplier server, the DN of this entry must be specified in the replication agreement.
The supplier bind DN entry must not be part of the replicated database for security reasons.
This entry, with its special user profile, bypasses all access control rules defined on the consumer server for the database involved in that replication agreement.
NOTE
In the Directory Server Console, this replication manager entry is referred to as the supplier bind DN, which may be misleading because the entry does not actually exist on the supplier server. It is called the supplier bind DN because it is the entry which the supplier uses to bind to the consumer. This entry actually exists, then, on the consumer.
8.1.6. Replication Agreement
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 and must specify all required replication information:
The database to be replicated.
The consumer server to which the data is pushed.
The days and times during which replication can occur.
The DN and credentials that the supplier server must use to bind (the replication manager entry or supplier bind DN).
How the connection is secured (SSL, client authentication).
Any attributes that will not be replicated (fractional replication).
8.1.7. Replicating Attributes with Fractional Replication
Fractional replication sets a specific subset of attributes that will not be transmitted from a supplier to the consumer. Administrators can therefore replicate a database without replicating all the information that it contains or all of the information in every entry.
Fractional replication is enabled and configured per replication agreement. Excluding attributes from replication is applied equally to all entries within the replication agreement's scope.
As far as the consumer server is concerned, the excluded attributes always have no value. Therefore, a client performing a search against the consumer server will never see the excluded attributes. Similarly, should it perform a search that specifies those attributes in its filter, no entries will match.
WARNING
Fractional replication can only be performed where the consumer is a read-only replica (dedicated consumer). This condition is enforced when the supplier server initiates a replication connection to the consumer, not when the agreement is created. It is therefore possible to create a fractional replication agreement on a supplier that will fail later when the supplier attempts to contact the consumer. This failure is logged in the supplier's error log.
8.1.8. Compatibility with Earlier Versions of Directory Server
The replication mechanism in Directory Server 8.0 is different from the mechanism used in 4.x of Directory Server. Compatibility is provided through two Directory Server plug-ins:
Legacy Replication Plug-in. The Legacy Replication Plug-in makes a Directory Server 8.0 instance behave as a 4.x Directory Server in a consumer role. For information on how to implement legacy replication using this plug-in, see
Section 8.15, “Replication with Earlier Releases”.
Retro Changelog Plug-in. The Retro Changelog Plug-in can be used for a Directory Server supplier to maintain a 4.x-style changelog. This is sometimes necessary for legacy applications that have a dependency on the Directory Server 4.x changelog format because they read information from the changelog. For more information on the Retro Changelog Plug-in, see
Section 8.16, “Using the Retro Changelog Plug-in”.
