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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
