be careful. in general, deleting transactions which haven't been applied to the database isn't a good solution. but since you're only using Berkeley for duplicate_db, which is non-critical, it is fine in your setting.
I don't know anyone who uses BDB for critical DB's in cyrus. They're too big for seen/sub state db's, too slow for enumerating across the mailboxes db, which really only leaves suplicate delivery and tls cache dbs.
This is really not neccassry unless the berkeley database is corrupt. Use 'db_recover' to reset the berkeley environment while cyrus server is not running.
We have seen many strange problems with BDB over the years. It's taken quite a bit of fiddling of /var/imap/db/DB_CONFIG values to get a BDB environment that will run stably over extended periods and loads and on large servers with growing user bases. Still we find if something does a little awry (eg a sudden load spike on the server), then BDB is usually the first thing to crap out. We have a process that continuously monitors the cyrus log and if it sees that BDB has gone into an error state, we just shutdown cyrus and restart. The fact the restart completely removes all BDB databases and logs almost always fixes the problem.
Why are folks still using DB3?
Old comment. It's db4 now. Rob ---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
