>>>>> On Wed, 3 Apr 2002 22:19:02 +0300, >>>>> Nick Ustinov <[EMAIL PROTECTED]> (nu) writes:
nu> We are planning to switch production server from 2.0.16 to 2.1.3/skiplist. nu> The system has about 600000 mailboxes and is quite heavily loaded (seeing nu> alot of db lockers). Are there any hidden catches people i should avoid? nu> Besides converting mailboxes file using cvt_cyrusdb is there anything else I nu> should know about? How about sieve scripts? Are these compatbile? Also, is nu> it recommended to switch to skiplist only for mailbox file or for the rest nu> as well? We're using skiplist for mailboxes.db and used the defaults for the others (BerkeleyDB 4.0.14 for deliver and tls stuff). Out of paranoia, this is what I did: 1. shutdown cyrus 2. drop in new binaries for 2.1.3, how ever you do that locally 3. su - cyrus # the user owning the /var/imap contents 4. cd /var/imap 5a. rm -f deliver.db tls_sessions.db # SEE NOTE BELOW!!! 5b. rm -rf db && mkdir db 6. cvt_cyrusdb `pwd`/mailboxes.db db3 `pwd`/mailboxes.db.new skiplist 7. mv mailboxes.db.new mailboxes.db 8. start cyrus 2.1.3 Note about #5a and #5b: I did this out of paranoia that I didn't want any old BerkeleyDB log files to have any relationship what so ever with my new skiplist mailboxes.db. I don't know if it would have happened, but I feared BerkeleyDB might try to replay any mailboxes.db log files. I don't think this would have been a problem because BerkeleyDB should have spit out mailboxes.db as being untasty. But, like I said, I was just being paranoid. Proceed at your own risk! ;-) Further note: the skiplist back-end also keeps a file in the db directory. So just because you should at some point drop BerkeleyDB all together, I wouldn't go and blow away that db directory without care. Just something to keep in mind. I ran the steps above on a test box first before doing them on our production server. Our mailboxes file had something like 65K folders in it. I forget the exact time, but it was incredibly fast to convert this on our Sun E250. Something like a couple of minutes. It has been doing swell since. :-) Oh, and using BerkeleyDB for deliver and tls stuff seems to be fine. The number of lockers will climb during peak periods, but then taper back down when traffic subsides. It just seems like mailboxes.db was an application not terribly well suited for it. -- Amos
