> 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:[email protected]] > Sent: 05 October 2012 20:24 > To: [email protected] > Cc: Osborne, Paul ([email protected]) > 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
