Chapter 7. Designing the Replication Process
7.1. Introduction to Replication
- Fault tolerance and failover — By replicating directory trees to multiple servers, the directory service is available even if hardware, software, or network problems prevent the directory client applications from accessing a particular Directory Server. Clients are referred to another Directory Server for read and write operations.
Note
Write failover is only possible with multi-master replication. - Load balancing — Replicating the directory tree across servers reduces the access load on any given machine, thereby improving server response time.
- Higher performance and reduced response times — Replicating directory entries to a location close to users significantly improves directory response times.
- Local data management — Replication allows information to be owned and managed locally while sharing it with other Directory Servers across the enterprise.
7.1.1. Replication Concepts
- What information to replicate.
- Which servers hold the master copy, or read-write replica, of that information.
- Which servers hold the read-only copy, or read-only replica, of that information.
- What should happen when a read-only replica receives an update request; that is, to which server it should refer the request.
7.1.1.1. Unit of Replication
7.1.1.2. Read-Write and Read-Only Replicas
7.1.1.3. Suppliers and Consumers
- In the case of cascading replication, the hub supplier holds a read-only replica that it supplies to consumers. For more information, see Section 7.2.3, “Cascading Replication”.
- In the case of multi-master replication, the suppliers function as both suppliers and consumers for the same read-write replica. For more information, see Section 7.2.2, “Multi-Master Replication”.
Note
For any particular replica, the supplier server must:
- Respond to read requests and update requests from directory clients.
- Maintain state information and a changelog for the replica.
- Initiate replication to consumer servers.
A consumer server must:
- Respond to read requests.
- Refer update requests to a supplier server for the replica.
In the special case of cascading replication, the hub supplier must:
- Respond to read requests.
- Refer update requests to a supplier server for the replica.
- Initiate replication to consumer servers.
7.1.1.4. Replication and Changelogs
nsslapd-changelogmaxage
or nsslapd-changelogmaxentries
. These attributes trim the old changelogs to keep the changelog size reasonable.
7.1.1.5. Replication Agreement
- The database to replicate.
- The consumer server to which the data is pushed.
- The times that replication can occur.
- The DN that the supplier server must use to bind (called the supplier bind DN).
- How the connection is secured (TLS, Start TLS, client authentication, SASL, or simple authentication).
- Any attributes that will not be replicated (see Section 7.3.2, “Replicate Selected Attributes with Fractional Replication”).
7.1.2. Data Consistency
- There is a reliable, high-speed connection between servers.
- The client requests serviced by the directory service are mainly search, read, and compare operations, with relatively few update operations.
- There are unreliable or intermittently available network connections.
- The client requests serviced by the directory service are mainly update operations.
- Communication costs have to be lowered.
- There is a latency in the propagation of update operations between suppliers.
- The supplier that serviced the update operation does not wait for the second supplier to validate it before returning an "operation successful" message to the client.