Marc Patermann wrote:
Hi,
Aaron Richton schrieb (23.02.2012 15:10 Uhr):
On Thu, 23 Feb 2012, Marc Patermann wrote:
The data set differs in a few entries which DEL were not replicated.
I tried (with various combinations of 2.4.26, 2.4.28 and current pre 2.4.30) to start the consumer with "-c rid=xxx,csn=" which starts a full sync, but the (on the master not existing) objects don't get deleted (on the slave).
Yeah, it's an impossible condition so it's not handled the best...
There is - however - a state where the consumer checks every entry for existence:
"slapd[23595]: nonpresent_callback: rid=402 present UUID a79a831e-f18b-1030-9aca-21c3336314b4, dn ..."
After this the consumer is exactly like the provider and all previous changes and DEL and synced.
But I'm not sure to always ensure how to achieve this state.
I deleted the database and put current master data in the provider and two day old slave data in the consumer. I started the provider and the consumer. This worked two times today, but later I was not able to reproduce it in all cases. This is a bit frustrating. :(
Is there any rock solid practice to get the consumer in the "check present" state?
Read RFC4533, there's no reason to take stabs in the dark.