Can I restore from ctl_deliver -d?

[Ian G Batten]

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 at uk.fujitsu.com> 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