[389-users] Re: enabled account policy plugin and incrace changelog db size

On 06/06/2017 06:52 AM, Alparslan Ozturk wrote:

The major probm is many user logedin conncurrency so replication not posible. I think this site must be developed or   high usage system must be schecled replication with optimum periots instead "real time".

You can setup a replication schedule, see:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-configuring_cascading_replication#Configuring_Cascading_Replication-replication-agreements

and

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-configuring-replication-cmd#Configuring-Replication-ReplAgmt-cmd

2017-06-06 13:47 GMT+03:00 Alparslan Ozturk <alparslan.ozturk@gmail.com>:

Dear Ludwin, I think you are right. The replication is complated with successfully. becasue I change replication aggrement.( every user loged in the lastlogintime changed ) , you know I have remove lastlogintime attribute the replication agreement.  

now changelogdb are trimmed multimaster sites. the size change between 1 -  2GB

-rw------- 1 nobody nobody 1,1G Haz  6 13:46 a8595502-446211e7-840bbe37-2d84af6b_55dc8a41000000010000.db

2017-05-31 10:04 GMT+03:00 Ludwig Krispenz <lkrispen@redhat.com>:

On 05/31/2017 01:44 AM, William Brown wrote:

On Tue, 2017-05-30 at 15:42 +0300, Alparslan Ozturk wrote:  

this is my person object and it has lastlogintime (the operational  attribute) so if many user bind the lastlogintime information updated so  replication is started. now I am changed agreement exclude lastlogintime  many replication is not accured. so changelogdb size slowly incrace. but  still incrace the size.      

I don't think you can use fractionalReplication like this. Because you  end up commiting a change on either A or B master that can't be resolved  by the other, so the cl will grow forever.     Allow the replication of the attr :) 

the changes will be logged independent if they are replicated or not, so trimming is the only way to limit the size.
if you mean that trimming doesn't happen if the change is not rpelicated, this should be handled by the regular update of the "keep alive" entry, which will be replicated and update the consumer ruv, so that trimming can procede

_______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org  To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org  

--   Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,   Commercial register: Amtsgericht Muenchen, HRB 153243,  Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org

_______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org  To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org