[Date Prev][Date Next]
Re: when to checkpoint?
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
> 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
> 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.