On 16 Oct 07, at 1259, Alain Spineux wrote: > Hi > > You are very conscientious. > Because deliver.db only avoid multiple delivery of the same email in > the same mailbox, > most of us should have skipped this. Multiple delivery should be very > rare, happend only once, and without consequences. > > Dou you know you can "expire" oldest entries in deliver.db using > cyr_expire ? > This could reduce the time processing and maybe avoid errors. I considered expiring it down to one day. But that would still have taken a few hours to flatten. Anyway, I just copied it from one machine to the new one, and it all worked fine. ian > > Regards. > > On 10/11/07, Ian G Batten <ian.batten@xxxxxxxxxxxxxx> wrote: >> I'm performing a migration from 2.2.8 on an E450 running Solaris 10 >> Beta Build 58 to 2.3.9 on a T2000 running Solaris 10 latest. The >> former isn't zoned (it wasn't available in that build), isn't smf'd >> (ditto) and isn't ZFS'd (ditto). >> >> The new machine has Cyrus in a zone, rooted on ZFS, with the local >> storage also on ZFS. >> >> The mailboxes themselves (35K mailboxes, a couple of terabytes) are >> on NFS storage (some on Sun, mostly on a Pillar), so I'm testing the >> new configuration by performing a metadata migration from read-only >> mounts. I've written a script to perform the migration in an rsync >> style, paralleled over the T2000, which is able to sync the metadata >> between the live storage and the new metadata partition in 35 >> seconds. >> >> Just to ensure the best health and hygiene, I'm rebuilding as many >> databases as I can. The mailboxes file is the result of ctl_mboxlist >> -d | ctl_mboxlist -u, the sasldb is the result of db_dump -p and >> db_load, etc, etc. >> >> However, the one that seems resistant to this is deliver.db (skiplist >> format). cvt_cyrusdb ... skiplist ... flat takes five hours before >> failing, and although ctl_deliver -d appears to run quickly and >> correctly, I can't see an immediately obvious way to reload it. >> Obviously, this isn't a big problem: I can just shut down the old >> Cyrus instance, copy the file over, and all is well. But having >> databases de-fragmented, built with the same bits that are in >> production, is a nice confidence booster if it's possible. >> >> ian >> >> ---- >> Cyrus Home Page: http://cyrusimap.web.cmu.edu/ >> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki >> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html >> > > > -- > Alain Spineux > aspineux gmail com > May the sources be with you ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
