skip to content

Replication & Referrals

2 roadmaps5 questions

Keeping several directory servers in step: single- versus multi-master models, content sync, referrals and chaining, and the staleness you accept. It explains why a password change has not landed yet.

on this pageshow

explore

questions

5

In a replicated LDAP directory, what does a multi-master write model permit that single-master does not, and what does it cost?

level: middleimportance: must knowfreq 48%

answer

  1. where a write is allowed to land
  2. one writable copy, or several
  3. ordering is free with one writer
  4. referral or chaining sends writes home
  5. conflict policy is not in the RFCs

basics

~20 s

Single-master accepts writes at one server, so every change has one order and contradictory writes cannot both be accepted. Multi-master accepts writes at several servers, keeping writes available when one fails, at the cost of conflicting concurrent changes that must be resolved afterwards.

solid answer

~40 s

In a single-master deployment one server holds the writable copy of a naming context and the rest hold read-only replicas. A write arriving at a replica is not applied there: the replica returns `referral (10)` naming the writable server, or chains the operation to it. Because every accepted change passes through one server there is one order, and two contradictory changes to a directory entry can never both be accepted — but writes stop entirely when that server is unreachable. Multi-master lets several servers accept writes locally and reconcile later, so writes survive the loss of one server; the price is that two servers can accept contradictory changes inside the replication delay. The LDAP specifications standardise the operations and the content synchronization operation, not which conflicting write wins — that is implementation policy.

code

ldif · 10 lines
ldif
dn: uid=aokafor,ou=crew,dc=example,dc=com
changetype: modify
replace: telephoneNumber
telephoneNumber: +44 151 555 0143
-

dn: uid=aokafor,ou=crew,dc=example,dc=com
changetype: modify
delete: telephoneNumber
-

go deeper

for a junior

Recall that only some servers in a replicated directory accept writes, and that the others hold copies. Know that a write sent to a copy is not silently applied there.

for a middle

Explain why one writable copy gives you a single change order for free, name the three conflict shapes multi-master creates, and say that resolution policy is the implementation's, not the protocol's.

for a senior

Show that you have operated one: what happens to writes when the writable server is unreachable, how a lost value under last-writer-wins is noticed, and how write routing is enforced rather than assumed.

for a principal

The tradeoff is write availability against a conflict policy you will own for years. Argue which failure your estate can actually absorb, and refuse a model whose losing-write behaviour nobody can describe.

## Where a write is allowed to land A directory is rarely one server. A shipping line keeps its crew roster as one directory entry per seafarer under a naming context such as `ou=crew,dc=example,dc=com`, and that content has to be readable from the shore office, from the manning agencies, and from vessels at sea. Copying content between servers is the easy half of the problem. The half that defines the deployment is **where a write is allowed to land**, because that one decision fixes whether contradictory writes are possible at all. ## Single-master: one writable copy Exactly one server holds the writable copy of a naming context; every other server holds a read-only replica of it. - A write arriving at a replica is not applied there. The replica either answers `referral (10)` carrying an LDAP URL that names the writable server, or **chains** the operation — performing it against the writable server itself and returning the outcome as though it had done the work. - Ordering is free. Every accepted change passes through one server, so there is a single order that all replicas eventually apply. - Two contradictory changes to one directory entry cannot both be accepted, so conflict resolution is not a design question you have to answer. - The writable copy is a single point of failure **for writes**. When the shore office is unreachable, a crew change cannot be recorded anywhere; reads carry on everywhere. ## Multi-master: several writable copies Several servers hold writable copies of the same naming context, each accepts writes locally, and each replicates them onward afterwards. - Writes survive the loss of one server, and a change can be recorded close to where it happens. - The cost is that two servers may accept contradictory changes inside the replication delay, and both are already committed by the time they meet. Three distinct shapes of conflict appear, and they are not one problem: 1. **Attribute conflict** — two accepted `ModifyRequest` operations set different values for the same attribute of one directory entry. 2. **Delete against modify** — one server deletes the directory entry while another modifies it, so after convergence the modification has no entry to belong to. 3. **Naming conflict** — two servers each add a directory entry that resolves to the same DN, which the tree cannot hold twice. ## What the specifications settle, and what they leave open RFC 4511 defines the operations and the result codes, including `referral (10)`. RFC 4533's content synchronization operation defines how a replicating client obtains a copy of a fragment of the tree and keeps it in step. **Neither defines a replication topology, and neither defines which conflicting write wins.** Resolution is left to the server implementation, and the usual policies are worth naming because each loses something: - last change wins, decided per entry — the whole losing change disappears, including attributes the other writer never touched; - last change wins, decided per attribute — finer, but two attributes of one entry can end up from different writers, which can be an inconsistent combination; - naming conflicts resolved by renaming one entry — nothing is lost, but the roster now has an entry under a DN nobody chose. Any of these can silently discard a change an operator believes was accepted, which is why the conflict question is an operational question and not only a protocol one. ## The two models side by side | | Single-master | Multi-master | |---|---|---| | Where a write is accepted | one server | any writable server | | Write availability | lost with that server | survives the loss of one | | Change ordering | one global order | per-server, reconciled later | | Contradictory accepted writes | impossible by construction | possible inside the replication delay | | A write sent to the wrong server | `referral (10)`, or chained | simply accepted locally | | What you must design | write routing | a conflict-resolution policy | ## What it costs the roster Under single-master, a crew change signed off ashore is written once and flows outward; a vessel that has been offline for three weeks is simply behind, and catching up is a content transfer with no ambiguity. Under multi-master, a master ashore and a master in a regional office can both record a crew member's shore-leave contact number in the same hour, and one of those values will not survive. Neither model is wrong. What is wrong is running multi-master and never answering the third question in the table's last row — because the policy exists whether you chose it or not.

  • Under single-master, what are the two ways a read-only replica can deal with a write it is handed?
    It can refuse and return `referral (10)` with an LDAP URL naming the writable server, leaving the client to open its own connection there and repeat the operation. Or it can chain: contact the writable server itself and return the result, so the client never learns a second server was involved.
  • Why is a delete-against-modify conflict harder to resolve than two conflicting attribute values?
    With two values there is still one entry, so a policy can pick a value and the entry survives. With a delete, one side has removed the object the other side's change belongs to. Reviving the entry resurrects something an operator deliberately removed; honouring the delete silently drops an accepted modification. Both outcomes surprise someone.
  • If multi-master needs a conflict policy, why does anyone choose it for a directory?
    Because write availability and write locality are worth real money. A directory that cannot record a crew change while one site is unreachable blocks work; a conflict on one attribute a few times a year does not. The choice is between a failure that is certain and rare and one that is occasional and small.

saying these in an interview costs you the question

  • Assumes the LDAP specifications define which conflicting write wins
  • Says a read-only replica queues writes and applies them later
  • Thinks multi-master removes replication delay as well as the single writer
  • Treats single-master as a read availability problem rather than a write one
  • Believes a naming conflict and an attribute conflict are the same failure
  • Calls last-writer-wins lossless because both changes were accepted
open as a page

For an RFC 4533 content synchronization session, when does refreshOnly fit a replica better than refreshAndPersist?

level: seniorimportance: must knowfreq 40%

basics

~20 s

refreshOnly fits a replica that cannot hold a connection open: it converges, receives a new syncCookie in the Sync Done Control, and disconnects, resuming later from that cookie. refreshAndPersist fits a replica with a stable link that should learn of each change as it happens.

open as a page

How does an LDAP referral reach a client as a result code, and how does a SearchResultReference differ from it?

level: middleimportance: should knowfreq 42%

basics

~20 s

An LDAP referral arrives as resultCode referral (10) on the operation's own result: the server did the operation nowhere and hands back one or more LDAP URLs. A SearchResultReference arrives mid-search, alongside real entries, saying part of the subtree continues elsewhere.

open as a page

In a multi-site LDAP directory whose replicas run minutes to weeks behind, how do you set a staleness window and decide which reads may not take it?

level: principalimportance: should knowfreq 30%

basics

~20 s

Publish a measured bound, not an aspiration: state how far behind a replica may be, measure it continuously, alarm when it is exceeded, and say what happens then. Then classify reads, and route every read that decides access or follows the reader's own write to the writable copy.

open as a page