[Freeipa-users] changing the default for changelog trimmimg

Petr Spacek pspacek at redhat.com
Fri Jul 3 12:43:52 UTC 2015


On 3.7.2015 14:41, thierry bordaz wrote:
> On 07/03/2015 02:28 PM, Petr Spacek wrote:
>> On 3.7.2015 14:21, thierry bordaz wrote:
>>> On 07/03/2015 02:03 PM, Petr Spacek wrote:
>>>> On 3.7.2015 11:45, thierry bordaz wrote:
>>>>> On 06/30/2015 03:54 PM, Ludwig Krispenz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> 389-ds allows to configure the max size of the replication changelog either
>>>>>> by setting a maximum record number or a maximum age of changes.
>>>>>> freeIPA does not use this setting. In the context of ticket
>>>>>> https://fedorahosted.org/freeipa/ticket/5086 we are discussing to change
>>>>>> the
>>>>>> default to
>>>>>> enable changelog trimming.
>>>>>>
>>>>>> Does anyone already use changlog trimming or is there a  scenario where you
>>>>>> rely on all changes being available ?
>>>>>>
>>>>>> Thanks for your feedback,
>>>>>> Ludwig
>>>>>>
>>>>> Hello,
>>>>>
>>>>>      I think it is reasonable to set nsds5ReplicaPurgeDelay and
>>>>>      nsslapd-changelogmaxage to similar value.
>>>>>
>>>>>      When a replica (master or consumer) is down for some time and is
>>>>>      restarted, both attribute express the ability to get the replica in
>>>>>      sync with the rest of the topology.
>>>>>      It can work (and likely will) if
>>>>>      nsds5ReplicaPurgeDelay<nsslapd-changelogmaxage but there are always
>>>>>      corner cases that can lead to problem (like entries that diverge).
>>>>>
>>>>>      Currently purgedelay=7days (default) and changelogmaxage is infinite
>>>>>      and changing purgedelay=infinite impacts the size of the entries.
>>>> I wonder if these values could/should be controlled by topology plugin. Does
>>>> it make sense to have different values on different replicas?
>>>>
>>> Purgedelay can be different on each replica but it makes sense that the value
>>> is the same on all replicas. It is used to remove too old csn and so how far
>>> in the past the replication can decide which value is more recent than an
>>> other one. With different values of purge delay, a replica can decide to keep
>>> one value and an other replica can decide the opposite.
>>> Currently purgedelay is identical on all replicas (default value).
>> I understand that technically it is possible so the question is more like
>> 'does it even make sense'? Do we want to support it?
>>
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaPurgeDelay.html
> 
> 
>    ...
> 
>    When setting this attribute, ensure that the purge delay is longer
>    than the longest replication cycle in the replication policy to
>    preserve enough information to resolve replication conflicts and to
>    prevent the copies of data stored in different servers from diverging.
> 
> The longest replication cycle is identical for all replicas, so it is a
> recommendation to use the same value.
> I admit it could be more clearly stated.
> 
> If one decides to go with different values and complains about entries that
> diverge, support will likely lead him to this page.

So .... moving forward, should we enforce one topology-wide value in topology
plugin? Is there a legitimate use-case for using different values?

-- 
Petr^2 Spacek




More information about the Freeipa-users mailing list