Ken,
A good way of getting around the NFS locking problem is to insert another
program inbetween tcpserver and qmail-smtpd that checks a database for a
relay flag (Which can be set when you call open_smtp_relay()).and that
program sets the RELAYCIENT.
Sean
----- Original Message -----
From: "Ken Jones" <[EMAIL PROTECTED]>
To: "Dave 'Duke of URL' Weiner" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 7:28 AM
Subject: Re: mysql high availability
> Hi Dave,
>
> Dave 'Duke of URL' Weiner writes:
>
> >> This is probably worth talking about now, since we are working
> >> on the mysql module for the next several weeks. Using Matt's
> >> read/update patch as a starting point the mysql functions
> >> are broken up into read-only queries and update queries
> >> with separate definitions in vmysql.h for two mysql login
> >> connections. One for updates and one for read only.
> >>
> >> I don't have any clean ideas yet on how to handle the
> >> three cases most people are running into:
> >> 1) one mysql server for everything
> >> 2) replicated mysql system, with one read only server (slave)
> >> and one update server (master)
> >> 3) a primary server and a backup server
> >>
> >> Anyone have any ideas?
> >
> > Why yes, Ken, I do :)
> >
> > First off, a very good start. As you and I have discussed before, I was
> > atempting a primary server with two slave servers replicating off the
> > master. Using Ben's patch, everything seemed to work quite well, using
the
> > hostname of the master as the "Write" server, and localhost as the
read-only
> > server. In testing, when the master write server was shut down, users
could
> > not authenticate via pop, as the login routines were attempting to write
the
> > ip address and other info for the pop-before-smtp files.
> >
> > My only suggestion would be not to store the pop-before-smtp data in the
> > MySQL database. That way, you end up with, IMO, a fault tolerant system
for
> > MySQL authentication.
>
> Yes, I was looking at that.
> The first thing that I ran into is trying to minimize database
> transactions during a pop access. The authentication part is
> easy, just read the user info from mysql.
>
> There are two optional transactions that do updates during
> an authentication
> 1) the roaming users --enable-roaming-users=y
> 2) authentication logging --enable-auth-log=y
>
> It seems pretty wasteful to have the authentication
> mechanism open two database connections, one for
> the read only auth and one for the two possible updates.
> But I really can not see a way around it.
>
> For the roaming users stuff to work, the IP addresses
> have to be centralized. Otherwise in a clustered setup
> once they pop, they may or may not be able to use smtp
> relaying. We have tried using a file based system with
> a NFS mount, but it runs into synchronization problems
> when multiple machines are updating the file at the same
> time, and locking doesn't help because NFS locks will
> fail.
>
> One thing we've been looking at is having "fall back"
> servers for both the read and update mysql connections.
> Meaning: if a connection to one fails, then it attempts
> a connection to the fallback machine.
>
> The other thing is the authentication needs to be compiled
> into the binaries. One other option is a patch from
> Ondrej that gets the mysql auth data from environment
> variables.
>
> Ken Jones
>
