[PATCH] do a partial replication with drs replicate --local
metze at samba.org
Thu Feb 2 08:21:41 UTC 2017
>> We should not construct a highwatermark on the client side!
>> You need to check if we have a repsFrom for the current dc
>> and get the highwatermark from there, otherwise we need to send an
>> empty highwater mark and just rely on the uptodatevector.
>> The uptodatevector also needs an entry for our self,
>> basically the logic from dsdb_load_udv_v2().
> So I can try and work with Bob on this tomorrow, what you are asking is
> that in addition to reading the replUpToDateVector the code should read
> the repsFrom?
> The reason we didn't rely on the repsFrom is that the use case for this
> tool will very likely not have a repsFrom for the target server, as it
> is trying to force a manual replication.
> In any case, preferring that seems reasonable, but why should we not
> use the USN from replUpToDateVector as a fallback, to reduce the
> processing required on the DC?
If the dc wants to reduce the processing load that should be done
as optimization on the source dsa within the DsGetNCChanges()
but that's nothing the client (destination) dsa should do.
> Can you fill me/us in on the the difference in behaviour you are worried about?
We use to do some magic regarding the highwater mark before
and it turned out to be a mistake.
Have a look at
git log -p --patch --reverse -18 f77bfed088b93f3ed0f00d0c172ad495c6c2b09b
The cient/destination dsa need to handle the highwater mark as on opaque
thing only valid relative to the invocationId that it belongs to.
> (I realise the > USN search in GetNCChanges is still un-indexed, but it
> is much faster now than it was in the past).
The source dc can do such optimizations...
> This tool is quite likely to be used in attempting to recover very
> large domains (which is currently much more difficult with the forced
> full replication in the current tool).
BTW: is there a command to recover everything from a remote server,
e.g. overwrite all local objects and attribute with the values from
the other server?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the samba-technical