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