Re: [exim] changing mailstores

> On 2012-10-05 at 15:17 -0400, Phil Pennock wrote:

> If the old server _dies_ for a period of time, you can do something
like
> nuke the wait-<old-server-transport> DB to force re-routing, right at
> the time you bring the server back up.

Now this I like the sound of, if only for the sheer brutality of the
approach. :)

> For this, you might want to have two identical transports, with
> different names, used for the old and the new routers, so that you can
> independently nuke them. That might be overkill.

Incidentally the 'new' mailstore will get dealt with by a different
transport anyway <cough>in the cloud</cough> so we have
overkill^Wflexibility built in by default.

Thanks

Paul

Paul Osborne
Systems Analyst
Infrastructure Group
Computing Services
Canterbury Christ Church University
Tel: +44 1227 782751


> -----Original Message-----
> From: Phil Pennock [mailto:exim-users@spodhuis.org]
> Sent: 05 October 2012 20:24
> To: exim-users@???
> Cc: Osborne, Paul (paul.osborne@???)
> Subject: Re: [exim] changing mailstores
>
> On 2012-10-05 at 15:17 -0400, Phil Pennock wrote:
> > If your volumes are such that you _need_ multiple mails in one
> > connection for the majority of mails, then things are more
complicated.
>
> Matthew Newton's answer is good and handles most cases; there's a
corner
> case of a message deferred before the pause is put in place (temporary
> glitch on remote server) which should be fairly rare; if that happens,
a
> mail can still trickle out to the older server. A minute of delay to
> let the volume of the rest of the mail take the message down the old
> connection, before the old mailbox is frozen/exported/whatever, should
> deal with that scenario.
>
> If the old server _dies_ for a period of time, you can do something
like
> nuke the wait-<old-server-transport> DB to force re-routing, right at
> the time you bring the server back up.
>
> For this, you might want to have two identical transports, with
> different names, used for the old and the new routers, so that you can
> independently nuke them. That might be overkill.
>
> -Phil