Chapter 15. Managing Replication
Replication is the mechanism by which directory data is automatically synchronized from one Red Hat Directory Server instance to another; it is an important mechanism for extending the directory service beyond a single server configuration. This chapter describes the tasks to be performed on the supplier and consumer servers to set up single-supplier replication, multi-supplier replication, and cascading replication.
15.1. Replication Overview
Replication is the mechanism by which directory data is automatically synchronized from one Directory Server to another. Updates of any kind — entry additions, modifications, deletion or renaming of an entry — are automatically mirrored to other Directory Servers using replication.
15.1.1. What Directory Units Are Replicated
The smallest unit 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 2.2, “Creating and Maintaining Databases”.
15.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 supplier 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.
15.1.3. Suppliers and Consumers
A server that holds a replica that is send to a replica on a different server is called a supplier for that replica. A server that holds a replica that is received 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 15.4, “Cascading Replication” has more information.
- In the case of multi-supplier replication, the suppliers are both suppliers and consumers for the same information. For more information, see Section 15.3, “Multi-Supplier 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 send data to multiple consumer servers.
15.1.4. Changelog
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 keeps 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-supplier replication.
When an entry is modified, a change record describing the LDAP operation that was performed is recorded in the changelog.
The changelog uses the same database environment as the main database. Implementing the changelog as part of the main database ensures the database and changelog are always synchronized, reduces the required database cache size, and simplifies backup and restore operations.
Important
The changelog only write changelog RUV entries to the database when the server is shut down, and otherwise the RUVs are managed in memory. When you back up the database of a supplier, use the
dsctl db2bak command or the web console. Both ways, the RUVs are written to the database before the backup starts.
In Directory Server, the changelog is only intended for internal use by the server.
15.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 in the
cn=configentry. - 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, 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.
- In a replication context, this entry, with its special user profile, bypasses access control rules defined on the consumer server for the database involved in that replication agreement. Note that, outside of the replication context, the replication manager is subject to ACIs when performing regular operations.
15.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 (TLS, client authentication).
- Any attributes that will not be replicated (fractional replication).
15.1.7. Replicating a Subset of Attributes with Fractional Replication
Fractional replication sets a specific subset of attributes that will not be transmitted from a supplier to the consumer (or another supplier). 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, not per entry. Excluding attributes from replication is applied equally to all entries within the replication agreement's scope.
For attributes that are defined as optional (
MAY keyword) in the schema, it is possible to set different attributes to be replicated for an incremental update and a total update. The incremental update list (nsDS5ReplicatedAttributeList) must always be set to enable fractional replication; if that is the only attribute set, then it applies to both incremental and total updates. The optional nsDS5ReplicatedAttributeListTotal attribute sets an additional fractional replication list for total updates. This is described in Section 15.11.1, “Setting Different Fractional Replication Attributes for Total and Incremental Updates”.
Note
An update to an excluded attribute still triggers a modify event and generates an empty replication update. The
nsds5ReplicaStripAttrs attribute adds a list of attributes which cannot be sent in an empty replication event and are stripped from the update sequence. This logically includes operational attribtes like modifiersName.
If a replication event is not empty, the stripped attributes are replicated. These attributes are removed from updates only if the event would otherwise be emtpy.
15.1.8. Replication over TLS
For security reasons, configure Directory Server instances involved in replication to only replicate data over a TLS connection. Note that if attribute encryption is enabled, a secure connection is always required for replication.
Prerequisites
Before you can configure replication over TLS, the following prerequisites are required:
- Configure both the supplier and consumer servers to use TLS. See Section 9.4.1, “Enabling TLS in Directory Server”.
- Configure the consumer server to recognize the supplier server's certificate as the supplier DN. Do this only to use TLS client authentication rather than simple authentication. See Section 9.9, “Using Certificate-based Client Authentication”.
Important
Replication configured over TLS with certificate-based authentication fails if the supplier's certificate is only capable of behaving as a server certificate and not also as a client during an TLS handshake. Replication with certificate-based authentication uses the Directory Server's server certificate for authentication to the remote server.If you usecertutilto generate the Certificate Signing Request (CSR), pass the--nsCertType=sslClient,sslServeroption to the command to set the certificate required type.
Configuring Replication over TLS
For details about configuring replication:
- When using user name and password authentication:
- When using certificate-based authentication, see Section 15.6, “Configuring Replication Partners to use Certificate-based Authentication”.
