If its failover you want how about using VMWARE,  that would let you run Mercury in a virtual machine and set up another virtual machine, hosted on a different physical server, to take over if the first one stopped working for some reason.   Both servers could obviously use the same queue hosted on a NAS device somewhere.

 As soon as I can get my lot to part with £1200 for two sets of bundled virtual OS and utilities thats where all or servers hosting databases, email etc are going.   Licensing is per CPU not per core so we can have two systems running virtual server for that price plus most of the monitoring and failover utilities we could need.   This seems much cheaper than other automatic failover systems I have looked at in the past.

Starting Mercury on a new system is a fairly trivial task for us at least all we need do is copy of move the disk with our mail on, change to the correct IP address and start the server.   We have done this a few times now when hardware fails, it takes about 2 minutes to be running with our more critical accounts already accessible, doing it manually.
 

Has anyone tried using 2 mecury installations to process the same shared queue?  I find myself in need of a secondary server to serve the same queue for better reliability, but I'm not sure if Mercury was designed to do this...?  Are there any potential problems I should be aware of?

On 12 Jun 2007 Pegasus Mail & Mercury - Automated Email  wrote:

> Has anyone tried using 2 mecury installations to process the
> same shared queue?  I find myself in need of a secondary
> server to serve the same queue for better reliability, but
> I'm not sure if Mercury was designed to do this...?  Are
> there any potential problems I should be aware of?
>

Can't share the queue in Mercury/32, you'll get duplications.

Is there a proper way to run two Mercury servers (one as backup to the primary)?

 

On 12 Jun 2007 Pegasus Mail & Mercury - Automated Email <webmaster@praktit.se> wrote:

> Is there a proper way to run two Mercury servers (one as backup to the primary)?

Not currently, Mercury/32 does not have a MX capability.  They is no why to automatically fall over to a backup system but of course you can have an identical system setup and ready to go on a backup host to take over when the primary fails.

Even if there was a MX capability there is no easy way for the MX host to take over the job of processing the submission queue and performing the duties of the IMAP4, POP3 and SMTP server.

Just to clarify a little: Mercury uses MX info for outbound emails. If you have two mx-pointers into your system and want to setup a shared system, they need to share the local mailbox directory on a SAN, but have separate queues. I myself have been trying, but not successfully, to set up a secondary system with a host forward - but it failes unless I cheat the DNS and create a third hidden DNS server with alternate info - but this solution was more trouble than useful.

 /Peter

I've actually got this to work.  The problem I had with it is spam coming in to the 2nd server.  Sometimes spam would cause the 1st server to put the 2nd one in the temp block list.  Which in turn would make the 2nd server keep slamming the 1st to push the mail

On 12 Jun 2007 Pegasus Mail & Mercury - Automated Email  wrote:

> Just to clarify a little: Mercury uses MX info for outbound
> emails. If you have two mx-pointers into your system and want
> to setup a shared system, they need to share the local
> mailbox directory on a SAN, but have separate queues. I
> myself have been trying, but not successfully, to set up a
> secondary system with a host forward - but it failes unless I
> cheat the DNS and create a third hidden DNS server with
> alternate info - but this solution was more trouble than
> useful.
>
>  /Peter
>

If this is Mercury/32 for all the systems you could try doing it the other way via pull system using a domain mailbox.  The secondary MX host would be doing the MX and putting the mail into the domain mailbox.  The primary host would be downloading the mail from the MX host using the X-Envelope-To: header only to deliver the mail.  This pulling could be going on all the time to make this automatic when the primary gets back online.