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
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
> 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
> 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.