On 05/10/2011 01:00 PM, Frank Elsner wrote:
> On Tue, 10 May 2011 12:19:42 -0400 Wesley Craig wrote:
>> It's usually possible in a murder configuration to do a zero downtime
>> upgrade by xfer-ing users to a backend running the new version. The admin
>> is then in control of how much index upgra
On Tue, 10 May 2011 12:19:42 -0400 Wesley Craig wrote:
> It's usually possible in a murder configuration to do a zero downtime upgrade
> by xfer-ing users to a backend running the new version. The admin is then in
> control of how much index upgrade load to inflict on the new machine.
I'm very
It's usually possible in a murder configuration to do a zero downtime upgrade
by xfer-ing users to a backend running the new version. The admin is then in
control of how much index upgrade load to inflict on the new machine.
:wes
On 10 May 2011, at 11:41, Henrique de Moraes Holschuh wrote:
> O
On Tue, 10 May 2011, Per Steinar Iversen wrote:
> Running a reconstruct on user.% before allowing in new mail, after the
> upgrade, seems to be a better and more orderly option than allowing
> sendmail to do the job?
That's certainly how we always do it here. We pause the new email feed at
the
> BTW: What happened to the rpms published by Simon Matter? Nothing to be
> found at http://www.invoca.ch/pub/packages/cyrus-imapd/ recently.
>
> -psi
>
>
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
http://www.invoca.ch/
Recently I upgraded a moderately busy Cyrus imap from 2.3.x to 2.4.7
I used one of the excellent rpms by Simon Matter and everything went
smoothly until the upgrade went live: New mail arrived at once and this
triggered an index upgrade, the log contains lines like "Index upgrade:
user.xyz (10
