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