[PATCH] do a partial replication with drs replicate --local

Stefan Metzmacher metze at samba.org
Tue Feb 7 12:32:26 UTC 2017


Hi Bob,

> Attached are an updated set of patches. We updated [3/5] to only send a
> non-zero highwatermark if it finds the appropriate repsFrom entry.

Thanks!

However, I still don't see the logic from dsdb_load_udv_v2() where we
add our own
entry to the uptodateness vector, can you have a look at that too?

BTW: the server optimization with an empty highwatermark can be found here:
https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=f3cac442dcae59d08c50365106b78f7fcdeb75f4

metze

> On 02/02/17 21:21, Stefan Metzmacher wrote:
>> Hi Andrew,
>>
>>>> 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()
>> implementation,
>> 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?
>>
>> metze
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170207/5cfcc7f7/signature.sig>


More information about the samba-technical mailing list