Another question about MUPDATE server

[Rob Siemborski]

On Mon, 24 Feb 2003, Etienne Goyer wrote:

> Thanks Rob for your answer so far.  Concerning the replication process,
> we where thinking about using something like heartbeat to monitor the
> service.  Once the master has been found inoperative, heartbeat should
> promote one of the replica as master, by running a script to restart the
> replica in server mode for example.

Okay, this is slightly different than what I thought you were saying.  I'm
assuming you're also playing some sort of game to get the DNS changed to
the new master (or the new master takes the IP of the dead machine).

> You mention consistancy issue.  What could these be ?  If it would be
> about changes not having been pushed to the replica, a work-around would
> be to recreate the MUPDATE database (?) from scratch from the backend
> (but this might be too prohibitive in wall clock time).

Imagine this:

BACKEND -> Master: RESERVE user.rjs3
Master -> BACKEND: OK
Master -> Replicas: RESERVE user.rjs3
BACKEND -> Master: ACTIVATE user.rjs3
Master -> BACKEND: OK
*MASTER DIES*

You now have an inconsistant database on your replicas.  Typically this
would be solved by the slaves resyncing when the master came back up, and
until then the mailbox is unavailable anyway.

If you're going to recreate the mupdate database from scratch anyway,
there's not much need of a hot spare.

Of course, it is slightly faster to rebuild the master mupdate database if
you have a relatively recent copy.

The bigger problem is more that mail to nonexistant mailboxes will be
rejected (which is why lmtpproxyd queries the mupdate master directly,
instead of relying on a replicated copy).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper