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:
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”.
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.
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:
In the case of cascading replication, the hub server holds a read-only replica that it supplies to consumers. Section 8.2.3, “Cascading Replication” has more information.
In the case of multi-master replication, the masters are both suppliers and consumers for the same information. For more information, see Section 8.2.2, “Multi-Master Replication”.
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.
In Directory Server, the changelog is only intended for internal use by the server. For other applications to read the changelog, use the Retro Changelog Plug-in, as described in Section 8.16, “Using the Retro Changelog Plug-in”.
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.
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.
For more information on creating the replication manager entry, see Section 8.3, “Creating the Supplier Bind DN Entry”.
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).
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”.