Yup,
Multi master setups are a huge problem in mysql.
if you do use slaves for just the queries, use MyIsam tables
(preferrable stored completely in memmory) to increase select speeds.
Im using mysql to run huge banner/advertisement systems, and thus i need
at least one update/insert per view. or i should store them outside of
the db, and thus i can;t use normal slaves. (because i'd still need to
connect to the master to make the update.)
star formation is the way to go, unless you have a huge amount of
changes on the master which make you need a seccond cascade in there to
load balance the updates and release the master from most of the slave
replication querys.
I think this step could also be done with LVS (having a couple of
slave's to retreive the updates from one master, balanced by LVS, ) and
then use them as masters for a couple of other normal query slaves.
greets
Bosco Lau wrote:
Lets forget about 'multi'-master scenario. It is basically an
unsolvable problem for MySQL (at the moment).
The only sensible muti-server setup for MySQL is 'single master' -
'mutiple slave', preferbly in 'star shape formation' i.e. each slave
connected directly to master. Also don't bother about 'dasiy-chaining'
the slaves, this creates a single point of failure (those were the
days of token ring networks) ;)
Jan Klopper wrote:
True,
But as soon as you start doing updates to the database you will
horribly screw up your data, because mysql can't propogate the
changes made on slaves back tot the master and so on.
This will lead to loads of inconsistency's in you database.
If you only need to do load (and i mean loads) of select query's with
no changes than you could very well use mysql slaves inside a LVS to
run these query's.
Even normal master-slave replication still gives loads of problems,
so anything cutting edge which might do the trich and allow for the
slaves to be full database servers (and thus capable of handling
updates/inserts/deletes) should not be trusted in my opinion.
Granted, if they get the slaves to also be masters to each other, and
they get it to pay nice, then we're all set to have the best and
fastests clustering database on the planet (except for oracle?),
Maybe it would be nice to get some people to take a look at this?
Im considering the use of a filesystem like coda to do two way file
replications, but maybe storing a filesystem inside a clustering and
two way updating mysql system is much better.
Francois JEANMOUGIN wrote:
Jan Klopper :
Sent: Wednesday, March 02, 2005 9:48 AM
To: aero_climb@xxxxxxxx; lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Mon + LVS for a mysql cluster
Romain,
There is not good sollution for mysql and clustering.
Tup tup tup. That's what is called an assertion, man :).
The current state of the artr for MySQL is to use an NBD cluster.
You can use
LVS to load-balance connections to your MySQL servers. You need a small
management server to manage it.
Now, to check whether a MySQL server is available or not, you have two
solutions (assuming you choose Keepalived):
Use a TCP_CHECK that will detect if the server accepts connections.
Use the check_mysql from nagios-plugins embedded in a MISC_CHECK
script.
Probably you can do more complicated things with THC but, I didn't
find time
yet to test it, so, I can't help.
François (et hop).
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|