Has anybody thought of running dbmail in an ndbcluster type database? I have not had the time to try this out, but from what I've read this would (if it is compatible with dbmail) solve these "multimaster" database replication issues.
Just my 2 cents. Angus On Wed, 19 Jan 2005 07:40:06 -0800, Steven Lynn <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > >
