Chapter 11. Managing Replication
11.1. Replication Overview
11.1.1. What Directory Units Are Replicated
11.1.2. Read-Write and Read-Only Replicas
11.1.3. Suppliers and Consumers
- In the case of cascading replication, the hub server holds a read-only replica that it supplies to consumers. Section 11.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 11.2.2, “Multi-Master Replication”.
db2bak.plPerl script or using the Directory Server Console if the server is kept running. The changelog only writes its RUV entries to the database when the server is shut down; while the server is running, the changelog keeps its changes in memory. For the Perl script and the Console, these changelog RUVs are written to the database before the backup process runs. However, that step is not performed by the command-line script.
db2bakshould not be run on a running master server. Either use the Perl script or stop the server before performing the backup.
11.1.5. Replication Identity
- 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.
11.1.6. Replication Agreement
- 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).
11.1.7. Replicating a Subset of Attributes with Fractional Replication
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
nsDS5ReplicatedAttributeListTotalattribute sets an additional fractional replication list for total updates. This is described in Section 11.9.1, “Setting Different Fractional Replication Attributes for Total and Incremental Updates”.
nsds5ReplicaStripAttrsattribute 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
126.96.36.199. The Replication Keep-alive Entry
keepalivetimestampattribute is updated on the supplier and replicated to the consumer. Because the
keepalivetimestampattribute is not excluded from replication, the update of the keep-alive entry is replicated, the CSN on the consumer is updated, and then equal to the one on the supplier. The next time the supplier connects to the consumer, only updates that are newer than the CSN on the consumer are searched. This reduces the amount of time spent by a supplier to search for new updates to send.
dn: cn=repl keep alive 14,dc=example,dc=com objectclass: top objectclass: ldapsubentry objectclass: extensibleObject cn: repl keep alive 14 keepalivetimestamp: 20170227190346Z
- When a fractional replication agreement skips more than 100 updates and does not send any updates before ending the replication session.
- When a master initializes a consumer, initially it creates its own keep-alive entry. A consumer that is also a master does not create its own keep-alive entry unless it also initializes another consumer.
11.1.8. Replication with 4.x Versions of Directory Server
- Legacy Replication Plug-in. The Legacy Replication Plug-in makes a Directory Server 9.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 11.20, “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 11.21, “Using the Retro Changelog Plug-in”.