Every so often a directory review turns up delta-syncrepl on a deployment with no reason to run it. Someone read that it was the more efficient replication mode and turned it on. It is efficient, for a narrow set of workloads that most directories never run. I ask what it was brought in to solve and usually get a shrug.
What delta-syncrepl actually buys you
Plain syncrepl, in refreshAndPersist mode, keeps a consumer current by shipping the whole
changed entry. Modify one attribute and the provider sends the entire entry across the wire.
Delta-syncrepl ships the individual modification instead. To do that it keeps a running log of
write operations in a second database, the accesslog, and the consumer pulls its changes from
there (syncdata=accesslog) rather than from the main DIT.
The saving on any single write is the difference between the size of the entry and the size of the change. That number on its own has never decided anything. What decides it is the multiplication: the per-write difference, times the number of entries you touch, times the number of consumers you feed. Drop any one of those factors and you will estimate this wrong.
For an ordinary user object the per-write difference is not worth chasing. The entry is a couple of kilobytes, you change one attribute, plain syncrepl ships a couple of kilobytes. Do that a few hundred times an hour and the traffic still rounds to zero on any link built this decade.
Where the multiplication bites
The first shape is the fat entry that changes one field at a time. The canonical example is a big
static group: member is a multivalued DN attribute, and a group of 20,000 people at fifty-odd
bytes per DN is north of a megabyte living in a single entry. Add or remove one person and plain
syncrepl ships the whole megabyte to every consumer. Delta-syncrepl ships the one add or delete, a
hundred bytes or so. If that membership churns all day, onboarding plus the quarterly reorg, you
are moving megabytes per change to carry kilobytes of actual news.
The second shape is sheer count, and it is the one people miss. Picture a carrier subscriber directory: 300 million entries, each one small and boring, call it two kilobytes. Now roll out a schema change, or set one new flag on every subscriber. Plain syncrepl ships all 300 million entries in full, 600 GB, to each consumer. Delta-syncrepl ships the modification, call it 150 bytes, and the same sweep is 45 GB. Multiply either by four replicas and it is obvious which one fits inside a maintenance window.
Under a million entries this is a non-event. A full sweep is a couple of gigabytes, you run it on a Tuesday, and nobody notices. The arithmetic only turns on you at scale, where one byte per entry is 300 megabytes and the link does not care how small your individual change was.
So the mode pays when entries are far larger than the changes made to them, or when there are enough entries that a small per-entry cost compounds into a large one, on a link where bandwidth is not free. If that does not describe you, and for most directories it does not, you are standing up a whole subsystem to optimize a cost you do not have.
Worth asking even if it does describe you: if the big sweep is a once-a-year event, do you want to
run an accesslog for twelve months to make one weekend cheaper? Often the better answer is to
batch the update, or to rebuild the consumers from a slapcat and slapadd load and skip
replication for that one job.
The back-of-the-envelope
You do not need a benchmark for this. One line of arithmetic gets you most of the way:
entries touched, times entry size, times consumers. That is what plain syncrepl puts on the wire. Swap entry size for change size and you have roughly what delta-syncrepl puts there instead. The gap between the two is the entire benefit. If that gap is not a number that changes a decision, you are done.
Run it twice. Once for steady state, where “entries touched” is your write rate over whatever window you care about. Then again for the worst planned sweep you can imagine, where “entries touched” is the whole directory. Most people only run the first one. The second is the one that hurts, and it shows up later as a migration weekend that does not finish.
Two things people get wrong on the inputs. Take entry size from slapcat on your biggest objects
rather than your median user, since the fat entries drive the number. And count consumers
honestly, including the DR site everyone forgets. If the consumer count turns out to be what is
killing you, a cascading topology moves that load off the provider and is a smaller change than
delta-syncrepl.
What it costs
The accesslog is a real database. It needs sizing and backup like any other, and its growth is
governed by a purge policy (logpurge, olcAccessLogPurge). Set it and forget it and it will
either fill the disk or purge history that a lagging consumer still needed. Add the extra overlays
and the more elaborate replication config, all of which has to be right on every node.
Then there is the quiet failure mode. When a consumer’s position is no longer in the accesslog, because it fell too far behind or the purge got there first, delta-syncrepl falls back to a full refresh from the main DIT. The fallback itself is fine. The problem is that it is silent, and it tends to happen under exactly the write pressure you deployed delta-syncrepl to handle. An undersized accesslog hands you plain syncrepl’s traffic plus the cost of running the accesslog on top. Nothing tells you. You either go looking or you don’t find out.
Earn it
This is the flat-file argument again: operational surface should be earned, not defaulted into. Every overlay and every extra database is a part somebody has to understand years from now, and per the reliability trap, the parts nobody understands are the ones that rot in place.
Run delta-syncrepl when you can point at the number. The megabyte group that churns all day, or the sweep across a few hundred million entries that has to land inside a window. Both are real, and when you have one, the accesslog is worth every bit of the trouble. Short of that, plain syncrepl has been quietly doing the job, and I would leave it alone.