Re: when to checkpoint?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Buchan Milne writes:
>On Wednesday 20 February 2008 21:00:42 Thomas Ledbetter wrote:
>> but would it make more sense to do this more frequently over the
>> course of the day to keep the checkpoint process less expensive per
>> iteration?
>
> IMHO, yes.

That also makes startup faster after an unclean shutdown, since slapd
needs to recover the database in order to start.

>>   What kinds of metrics should be used to determine how frequently
>> this should be done?
>
> This would depend on the frequency of changes, and how long you can
> afford to have database recovery run for. I usually go with something
> around 5-10 minutes.

At our site we usually run read-only and then once in a while apply a
lot of changes at once - and we care about read and startup speed but
not much about update speed.  So we've tried even briefer, 2 minutes.
Seems to work fine.  Need to experiment with taking slapd up and down
and see what happens though.
  checkpoint      1024 2
  dbconfig        set_flags DB_LOG_AUTOREMOVE

>>   If I have two master servers keeping, say, a week's worth of
>> transaction logs, a sound archival process, and a backup LDIF, would it
>> make sense to just disable transaction logging altogether across the
>> replicas?
>
> If you can afford taking a slave down for a re-import or re-sync, maybe.
> However, I would sacrifice a bit of performance to avoid this myself.

If you need translation to Berkeley DB parlance, if I've got it right:
You don't need _catastrophic_ recovery for the slaves - that implies
manual intervension, and then you can just as well use the backup of the
master slapd.  However if you disable _normal_ recovery on the slaves,
then they'll also need manual help to start after an otherwise harmless
system or application failure.

-- 
Hallvard