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.