I have actually been using this for some time now. I used it, originally, on two routers and point all of my Windows boxes at the shared ip. That way I could mess with one, if it failed, the second box would take over and no one would know. I just started to use it for my two mail servers... Very nice and very easy to setup... Hardest part was getting the options correct... Just be careful, it does add some network bandwidth, so if you already have a heavy load, it will add about another 2-3k per second...
On Wed, 2005-01-19 at 10:23 -0500, Doug Stanley wrote: > Something I've been meaning to look into that may help in this area > is ucarp: > http://www.ucarp.org/ > Basically the idea is you have two mysql db's, either in a single > master/slave relationship or even in a double master... > ucarp will monitor both machines and send heartbeats back and forth > and if one dies, the other one takes over the ip address. So you can > have your dbmail stuff always point to say, 192.168.5.2 and ucarp > will make sure one of the two db's always has that ip... > And like i said earlier, just use replication between the two to > make sure they're sync'd. ucarp also supports firing off a script > when it swaps ip's, so as part of that you can have the slave db > switch configs and become the master db too... > > Not as good as mysql clustering...but something that should atleast > work right now... > > Doug > > M. J. [Mike] O'Brien wrote: > > Hey Steven: > > I have numerous replicating setups in a number of places and generally > > consider the solution as a stable one. > > Uptimes (synced) are very good even on the very busy mail servers. Actually > > I have never had a server break 'sync' save when I caused it by doing some > > kind of radical surgery on something. > > > > Failover, however is not very straightforward. I would love to hear your > > ideas. I rely to some extent on MX2 and have Postfix queue the mail until a > > decision is made on whether the downed server is to be returned to service; > > or a slave promoted to master and pushed up to MX1 production as the master > > is permanently killed. I keep an alternate 'my.cnf' on the slaves. In some > > cases the slave runs the MX2. > > > > Certainly when a replication slave breaks it can be a real pain because in > > most cases a tarball of a locked master's data must be used to update the > > slave. > > > > Usually, in my experience, the break has a reason; something significant and > > glaring. > > > > > > 1) I find that replication works best when the version of the master and > > slaves are identical. (i.e.: all v4.0.20 or whatever) > > > > 2) RW on the master; read-only on a slave. > > > > 3) Although there are many permutations possible, it is better to replicate > > the entire database and *not* have any additional databases on the slaves. > > > > 4) Don't mix character sets. Use the same global character set on all > > servers and use the same character set as global for all sessions. > > > > 5) Start out from a perfect mirror database set. > > > > > > I am sure you have a master/slave create routine but you might take a look > > at this one I know functions well and see if you are leaving something out. > > > > > > > > * stop the slave > > > > ON MASTER > > > > mysql > show master status\G > > *************************** 1. row *************************** > > File: master-bin.190 > > Position: 28903417 > > Binlog_do_db: > > Binlog_ignore_db: > > 1 row in set (0.00 sec) > > mysql > > > > > Note the first two lines. > > > > * Lock or stop the master and tarball the FULL contents of the data folder. > > ( i.e: cd ../data & /usr/bin/tar -cvf /export/home/tmp/mysql-snapshot.tar > > .. ) > > > > * move the tarball to the slave's data folder and untar it there. > > > > * start the slave > > > > * start the master > > > > NOW GO TO SLAVE CONSOLE > > # mysql -u root -p > > password secret etc > > > > mysql > stop slave; > > mysql > CHANGE MASTER TO MASTER_HOST='xxx.xxx.xxx.xxx.', > > MASTER_USER='dbmaster', > > MASTER_PASSWORD='dbpass', > > MASTER_LOG_FILE='master-bin.190', > > MASTER_LOG_POS=28903417; > > mysql > blah blah rows (secs) > > mysql > start slave; > > mysql > show slave status\G > > > > > > hope this helps... > > Mike > > > > > > > > > > > > > > ----- Original Message ----- > > From: "Steven Lynn" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Wednesday, January 19, 2005 1:22 AM > > Subject: [Dbmail] dbMail with MySQL Replication... > > > > > > > >>I know that this is probably a MySQL question, but I figured I would > >>start here. Hope no one minds... > >> > >>Is anybody using multiple dbmail servers that are also running MySQL > >>with replication? I have two servers and trying to do fail over between > >>the two. I can not seem to keep the two servers in sync. If I leave both > >>running, within 24 hours, one is out of sync... > >> > >>Anybody got any ideas? Once again, sorry for this question... > >> > >>-- > >>Steven Lynn > >> [EMAIL PROTECTED] > >> > >> > > > > > > > > ---------------------------------------------------------------------------- > > ---- > > > > > > > >>_______________________________________________ > >>Dbmail mailing list > >>[email protected] > >>https://mailman.fastxs.nl/mailman/listinfo/dbmail > >> > > > > > > _______________________________________________ > > Dbmail mailing list > > [email protected] > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail
