<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 07/03/2015 02:28 PM, Petr Spacek wrote: </div> <blockquote cite="mid:55967FF9.5030309@redhat.com" type="cite"> <pre wrap="">On 3.7.2015 14:21, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 07/03/2015 02:03 PM, Petr Spacek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 3.7.2015 11:45, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 06/30/2015 03:54 PM, Ludwig Krispenz wrote: </pre> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/5086">https://fedorahosted.org/freeipa/ticket/5086</a> 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 </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">I wonder if these values could/should be controlled by topology plugin. Does it make sense to have different values on different replicas? </pre> </blockquote> <pre wrap="">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). </pre> </blockquote> <pre wrap=""> I understand that technically it is possible so the question is more like 'does it even make sense'? Do we want to support it? </pre> </blockquote> <a class="moz-txt-link-freetext" href="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">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</a> <blockquote><tt>...</tt> <tt>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. </tt></blockquote> 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. </body> </html>