> same time, and what are the chances of that...  The other 
> option though, is that vpopmail does support a master/slave 
> setup where any writable queries go to server X while 
> readable ones are done locally for performance.  This is a 
> better scenario than two way replication since you don't run 
> the risk of replication breakage.

We have been running this particular setup for about a year now... I am
happy with the overall performance, however when things break, they have
a tendancy to break badly especially with MySQL's replication.

We had a problem with our NFS store dropping out from under the NFS
server* (the DBs were located on the same machine). This forced a hard
restart on the server and when the server would come back up the
replication in MySQL was broken between the master and slaves (the
master had a different replication point than the slaves, the slaves
were requesting a start position that didn't exist. The worst part is we
didn't realize it initially until updates to users, etc weren't being
seen on the slave servers). This forced us to down the local database
servers (slave database servers). This did have the advantage of forcing
vpopmail to look at the master server for reads and writes which was a
nice fall back position, but the restoration process was difficult and
depending on the amount of data in the vpopmail database, very time
consuming moving massive database dumps to resync the databases on the
slave servers.

I have had to do this process about 5 times since we have started
running this setup. Also if you are going to do this, be sure that when
you do a mysqldump of your data (you are doing that nightly right?;) )
be sure to use the --master-data option so the slaves will know where to
pick up replication with the master. Another tip... Turn off auth
logging to mysql if you are doing replication... ICKY.

* The problem was with an external RAID5 enclosure. The backplane had a
problem on one of the SCSI ports. We moved the SCSI connection over to
the second port and the server hasn't given us trouble since then.

We are currently looking at a load balancer solution (UltraMonkey/LVS or
Foundry ServerIron, still haven't decided but UltraMonkey/LVS is working
well so far) with DRBD (http://www.drbd.org/) and heartbeat for both the
database and NFS servers and cheap clones as the actual mail servers
running a combination of qmail+vpopmail+clamav+spamassassin.

Testing and tweaking for now...

Tom Walsh
Network Administrator

Reply via email to