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
begin:vcard
fn:Douglas Stanley
n:Stanley;Douglas
org:Integrated Marketing Technologies;IT
adr:;;2945 Carquest Dr.;Brunswick;Ohio;44212;US
email;internet:[EMAIL PROTECTED]
title:Systems Administrator
tel;work:330-220-6715
x-mozilla-html:FALSE
url:http://www.imtco.com
version:2.1
end:vcard
