reoccuring DBERRORs

[Rob Mueller]

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