I can tell you how we solved this problem. we have a 24/7 op where we need to constantly pull data from mysql machines. This data can be updated at anytime by our tools, but the live servers will only be reading data. So we have one machine which is connected to our tools box, this is where all of our updates go, then we use one way mysql replication to the 2 machines we have in the datacenter. Our app picks one of these at random, if it can't get a connection, it will try the other one. We find that we actually get pretty good load balancing on these machines. We've also been able to turn off one machine to do upgrades and such, and found that we don't suffer any downtime. btw, the machines that are in prod are Sun E250's but the machine that is connected to the tools is a linux box. I don't see any problems doing this with linux hardware, we just prefer sun's for our prod db's.
hope this helps.. --shak Barry Roomberg wrote: >I'm trying to determine the "correct" way of >dealing with a high availability situation, >which might also be a high performance (spread queries >across multiple systems) situation. > >I've "googled" for MySQL cluster, and found one >project that last seems last touched a year ago. > >1) All data is readonly. No write requirement except >monthly load. > >2) We'd rather spend money on hardware and MySQL support >than Oracle or some other commercial database. Hardware >and MySQL is scalable at a reasonable price, Oracle is not. > >3) This will be a 24/7/365 environment, so there can't be >any single points of failure. > >4) I already have the back end disk, so new purchase there >is not an option. Same with network gear and fibre channels. >Systems may be purchased, but we'd prefer to reuse current until >we have to get more. > >5) I can have dual net cards and dual fibre-channel cards >in each system, along with 2 net switches and 2 FC switches, >to allow full matrix connectivity. > >6) I've already proven that the data can be served by MySQL >in a rapid fashion, now I need to prove it can be continuous. > >1st Goal: Setup 2 systems that share data and allow >either to satisfy read requests. Seems like a simple >replication to 2 box scenario, with application level >handling to go to the "live" box if 1 is down. Are there >any preferred projects that handle the "director" portion >of this? I assume I will have total data duplication on each >system, ie: they won't be reading the same disk. > >2nd goal: Setup a cluster of systems sharing the same >disk (it is a fibrechannel back end). I ASSUME I can >read/only mount to a BUNCH of independent systems, which >will then serve queries. Simple? Seems so. Can MySQL >open a database "read-only" of a truly read-only file system? >The actual performance the disk is capable of providing >is far more than MySQL reads for a query, so I should be >able to stacka few systems against it before it degrades. > >There will not be a regular SQL connection to these systems, >there will be an application specific deamon handling requests >via network pipes, so I don't nead to deal with client side >issues (yet). > >Feel free to point me in a FAQ/Doc direction, I love to read. > >Thanks > > >--------------------------------------------------------------------- >Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > >To request this thread, e-mail <[EMAIL PROTECTED]> >To unsubscribe, e-mail <[EMAIL PROTECTED]> >Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > -- Shakeel Sorathia Systems Administrator (626) 660-3502 --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
