"Dieter Kluenter" dieter@dkluenter.de writes:
Hi,
Mavric Domen d.mavric@iskratel.si writes:
Hi,
I'm facing a similar issue, but I've noticed that this only happens if one of the master "consumer" servers is restarted. Up to that time it seems the synchronization works perfectly. I had no chance to investigate this in details, but it might help to discover a reason for the problem.
[...]
I have just modified test050 to meet my requirements and this seems to work. I will now pass this all over to slamd and do some testing.
I still have some issues with n-way replication. It seems that after a modification to the dataset contextCSN is not propagated to peers. With a standard syncrepl after a modifcation I see the propagation, but not with n-way replication.
,----[ log og standard syncprov replication ] | syncprov_sendresp: cookie=rid=001,csn=20081022161125.056721Z#000000#000#000000 | slap_graduate_commit_csn: removing 0xe20d40 20081022161125.056721Z#000000#000#00 | 0000 | syncprov_sendresp: cookie=rid=002,csn=20081022161125.056721Z#000000#000#000000 | slap_queue_csn: queing 0x427f5280 20081022161245.349623Z#000000#000#000000 | slap_graduate_commit_csn: removing 0xe21760 20081022161245.349623Z#000000#000#00 | 0000 | syncprov_sendresp: cookie=rid=002,csn=20081022161245.349623Z#000000#000#000000 | syncprov_sendresp: cookie=rid=001,csn=20081022161245.349623Z#000000#000#000000 `----
With n-way replication the contextCSN gets modified on the present master, but not on the peers:
initial contextCSN on localhost contextCSN: 20081022151212.263032Z#000000#000#000000
initial contextCSN on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000
after a modification on localhost entryCSN: 20081022151026.029523Z#000000#000#000000
on remote peer contextCSN: 20081022151212.263032Z#000000#000#000000
I just wonder wether this is a new bug or is it silly me.
-Dieter