Learn LDAP - Replication

#Introduction

In episode 12 you applied password policies on a single server. Now imagine the organization starting to grow: applications spread across several locations, and a single server becomes a point of failure and a bottleneck. Episode 13 answers this with replication — how directory data is copied automatically from one server to another using the syncrepl protocol you already glimpsed as one of the overlays in episode 11.

#Replication Concepts

Replication in OpenLDAP revolves around two basic roles:

Provider (formerly called master) — the source server that accepts writes and distributes changes.
Consumer (formerly called replica or slave) — a server that receives a copy of the data and serves searches.

The terms master and slave have now been replaced by provider and consumer because they describe the relationship more accurately — a consumer in one replication could itself be a provider for another consumer. Changes are distributed with the syncrepl protocol, which is essentially a persistent search: the consumer opens a connection and the provider sends every modification that occurs.

OpenLDAP's replication modes are: single-master (one provider), mirror mode (two servers that both accept writes), and N-way multi-master (all servers can accept writes).

#Replication Modes

Three syncrepl synchronization modes you must understand:

Mode	How it works	Characteristics
`refreshOnly`	The consumer polls the provider periodically	Polling, has an `interval`, good for low bandwidth
`refreshAndPersist`	The provider pushes changes immediately and keeps the connection	Real-time push, changes arrive without waiting for an interval
delta-syncrepl	The consumer requests only changes since a given point	Efficient, requires accesslog on the provider

In refreshOnly, the consumer asks the provider every interval and receives a full snapshot of changed data. refreshAndPersist starts with an initial snapshot then keeps the connection open — subsequent changes are sent directly. Delta-syncrepl uses a change log (accesslog overlay) so only the delta is sent, not the whole context.

#Single-Master Replication

The most common setup: one provider writes, one or many consumers read. The consumer needs a dedicated bind account, created as an ordinary entry — e.g. cn=replicator,dc=example,dc=com — with read and search ACL rights over the whole suffix.

Entry for the replication account

dn: cn=replicator,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: Replication bind account
userPassword: rahasia-kuat-123

On the provider side, enable the syncprov overlay:

olcSpCheckpoint: 100 10 saves the sync log every 100 operations or 10 minutes, and olcSpSessionlog limits the number of changes retained for offline clients.

On the consumer side, add the olcSyncrepl attribute to the database:

rid is a unique replication identity per server. To test, make a modification on the provider, then search the consumer and compare contextCSN:

Testing the replication result

ldapmodify -x -D cn=admin,dc=example,dc=com -W
ldapsearch -x -H ldap://ldap02.example.com -b dc=example,dc=com contextCSN

#Delta-syncrepl

To have only changes sent (not the entire dataset), install the accesslog overlay on the provider. This helps a lot with many consumers and limited bandwidth:

The consumer then adds syncdata=accesslog to its olcSyncrepl, and the provider runs the syncprov overlay on top of the accesslog database. Changes are forwarded as log entries instead of raw data, making replication traffic much lighter.

#Mirror Mode and Multi-Master

When single-master isn't enough, you can have more than one server accept writes. Mirror mode is the two-node form: both servers accept writes and replicate to each other, with olcMirrorMode: TRUE on both sides. N-way multi-master opens this to many nodes at once.

On the second server, olcServerID becomes 2 ldap://ldap02.example.com. Each node still runs syncprov and mounts olcSyncrepl to the other.

The most important consequence of multi-master is write conflicts. OpenLDAP resolves them by comparing contextCSN — the change with the largest (newest) CSN wins. This means if two admins change the same entry on different servers, the outcome is decided by time, not human order. That's why you should avoid multi-master unless you really need it; mirror mode is usually enough and far easier to predict.

#Monitoring Replication

Replication must be watched, not installed and forgotten:

contextCSN — this value identifies the synchronization point. A lagging consumer has an older contextCSN than the provider.
Replication lag — compare the timestamp in contextCSN on both servers; the difference is the lag.
Sync state — the olcSyncrepl bind results and slapd logs show sync messages like syncrepl_entry when an entry is synchronized.
Troubleshooting — check the cn=replicator credentials, make sure the ACL grants read access, and verify that port 389 is reachable from the consumer to the provider.

Viewing contextCSN on both sides

ldapsearch -x -H ldap://ldap01.example.com -b dc=example,dc=com contextCSN
ldapsearch -x -H ldap://ldap02.example.com -b dc=example,dc=com contextCSN

Tip

Write a simple script that fetches contextCSN from the provider and all consumers, then computes the difference. A healthy replication has a difference of seconds on refreshAndPersist; a growing difference signals a network problem, credential issue, or overload.

#Best Practices

Master on a protected network — keep the provider in a segment only internal servers can reach.
Replicas for read scaling — point application searches and binds at consumers, writes at the provider.
Monitor replication lag — growing lag is an early symptom of failure.
Test failover scenarios — shut down the provider, promote a consumer (enable read-write), then restore; do this periodically.
Backup strategy — back up data from the provider or consumer without disrupting service; slapcat on either node remains valid because the data is identical.

#Closing

In this episode 13 you understood OpenLDAP replication: the provider and consumer roles, the syncrepl protocol, the differences between refreshOnly, refreshAndPersist, and delta-syncrepl, single-master configuration with the syncprov overlay, mirror mode and multi-master with olcServerID, conflict resolution via contextCSN, lag monitoring, and best practices for failover and backup.

Key takeaways:

Provider writes, consumers read — the single-master pattern is the safest default.
refreshAndPersist is the common mode — changes arrive in real time without polling.
Delta-syncrepl saves bandwidth — but requires accesslog on the provider.
contextCSN is the health gauge — lag is a symptom, not something to treat as normal.

In the next episode, episode 14, we cover LDAP indexing — how olcDbIndex makes searches fast and prevents slapd from scanning the entire database. The replication you built will depend heavily on correct indexes on the consumer side.