Hi!

I’m getting more experience with delta-syncrepl, but I still have two questions I’m unsure about:

1. In contrast to plan syncrepl, is it true that plain syncrepl will sync contents “from the past” (i.e. content changed before syncrepl had been activated), whereas delta-syncrepl will nor sync changes that were made before delta-syncrepl had been activated (i.e. sync only “new changes”” mad after the delta-syncrepl configuration? (see below, also)
2. Is it expected that the entryCSNs are identical for a synced entry on each server? I use a check that compare the UUID and the CSN for each entry to verify synchronization, but I see small differences (example below)

For question #1: Specifically I have these messages (from today when establishing a new RID) in mind:

slapd[22664]: conn=35370 op=2 syncprov_findbase: searching

slapd[22664]: conn=35370 op=2 syncprov_op_search: registered persistent search

slapd[22664]: conn=35370 op=2 syncprov_play_accesslog: accesslog information inadequate for log replay on csn=20250707100648.450369Z#000000#001#000000

slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_CSN csn=20250707100648.450369Z#000000#001#000000

slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn==20250707100648.450369Z#000000#001#000000 not found

slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn<=20250707100648.450369Z#000000#001#000000 found

slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_PRESENT csn=

slapd[22664]: conn=35370 op=2 syncprov_sendinfo: present syncIdSet cookie=

(and actually some changes made on that server recently were not synced to the other servers that should “pull” from this one)

For question #2:

On example I found (comparing server #2 with server #3) was:

-uid=… (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.785857Z#000000#002#000000

+uid=… (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.780532Z#000000#002#000000

So there’s a difference in the 5ms area, and (AFAIK) both changes originate from server #2.

The corresponding changelog looks like this:

dn: reqStart=20250716105944.000001Z,cn=changelog-1

objectClass: auditModify

structuralObjectClass: auditModify

reqStart: 20250716105944.000001Z

reqEnd: 20250716105944.000003Z

…

entryCSN: 20250716105944.780532Z#000000#002#000000

…

And that change is the only change made that second.

Server #2 logged for sending the change to server #3:

slapd[1811445]: conn=1020 op=2 syncprov_sendresp: to=003, cookie=rid=112,sid=002,csn=20250716105944.780532Z#000000#002#000000

Server #3 logged for receiving the change:

slapd[2528537]: conn=-1 op=0 syncprov_add_slog: adding csn=20250716105944.780532Z#000000#002#000000 to sessionlog, uuid=c3e62200-55af-1038-9b76-9916ef1a4822

slapd[2528537]: slap_queue_csn: queueing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000

slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000

slapd[2528537]: slap_queue_csn: queueing 0x7f2d4818bf70 20250716105944.780532Z#000000#002#000000

slapd[2528537]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=reqStart=20250716105944.000001Z,cn=changelog-1 on opc=0x7f2d48002be0

slapd[2528537]: conn=1008 op=2 syncprov_qresp: set up a new syncres mode=1 csn=20250716105944.780532Z#000000#002#000000

…

slapd[2528537]: do_syncrep2: rid=113 cookie=rid=113,sid=003,csn=20250716105944.780532Z#000000#002#000000

slapd[2528537]: do_syncrep2: rid=113 CSN too old, ignoring 20250716105944.780532Z#000000#002#000000 (reqStart=20250716105944.000001Z,cn=changelog-1)

slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4814fd10 20250716105944.780532Z#000000#002#000000

(next change was several minutes later; rid113 would mean server #3 (sid 3) would try sync to itself (MMR on cn=config artefact))

Kind regards,

Ulrich Windl