> > Assuming majordomo2 works the same way majordomo does, it
> just keeps
> > the list config and subscription options in plain text files.
>
> Binary, Berkeley DB files for just about everything ...
Yikes. That makes things significantly harder, but I'm sure you could do
something along the line of a dump on one and restore on the other.
> > Then you set up a second MX record pointing to the
> secondary machine
> > *with a different priority value*. That way mail is only
> delivered to
> > the secondary machine if the first fails. Notes on this:
>
> It wouldn't be a backup in the sense of failover if the main
> server reboots, only if it totally goes up in smoke, at which
> point we'd need to failover the whole VM ... and this needs
> to go onto a non-US server, which I've got lined up in the
> EU, just haven't had time to move forward with ...
Uh, yes it would, wouldn't it? When the server reboots, it stops
responding on port 25. At which point a sending mailserver trying to
deliver a mail tot he list will switch to using the secondary MX machine
(with a higher priority), and deliver through that one.
It would not handle new subscriptions etc, but it shuld handle delivery.
> > How are these things set up now? I see svr1, 2 and 4 all
> handle mail
> > for postgresql.org, but do they do anything more than just
> queue it up
> > until the primary (svr1) is back up?
>
> Purely queuing ...
Ok. That's what I thought. With that solution, mails will not be lost,
but we have no delivery during the downtime.
//Magnus
