I totally agree with you not using mysql cluster product. Since I think it brings more burden and doesn't work on some locales (it was stated on mysql clustering Faq) also I have deep suspicions about totally in-RAM databases. But I want to ask the plan that I am thinking to install is right from the perspective of a man who install cluster. (Which seems to be the right solution to me). I am planning to install 1 rhcs+gfs with two nodes that works active-passive(this cluster will be mysql write server) since I think active-active hasn't been tried before with gfs+rhcs+mysql and I plan to mount the gfs partition (which is on a iSCSI) on my msqyl read servers and use these servers as a backend of load balancing server. Another option can be to make replication via mysql so use read-servers' I/O other than using shared storage's I/O. But I am not sure which to install. but the second one seems to be a better solution because I don't want to make high I/O load on my iSCSI because if I connect say 5 mysql read server it may saturate my iSCSI box. I really appreciate your answers about my question and want to thank in advace. > I think the MySQL Cluster product and what I was describing > were two different things. > > I wasn't talking about using the MySQL Cluster product, > just running regular MySQL on two separate RHCS nodes > that have a shared GFS filesystem. > > It appears that the MySQL Cluster system, from what I > can find, is more like a network-aware locking mechanism > at the MySQL layer that works only with in-RAM databases. > It also looks like you need a front-end SQL node to sit > in front of the two (or more) server nodes, an administration > node, etc. > > Overall, the MySQL Cluster system looks like a stand-alone > cluster product, whereas I was trying to say that I was > going to run two normal MySQL processes on two RHCS nodes, > which from a different perspective could be seen as running > two MySQL server instances pointing at the same datadirs > using flock() to lock between them. > > Since GFS makes flock() cluster-wide, and this appears > to be the only arbitration between multiple MySQL server > instances, then GFS would allow multiple MySQL server > instances to run on different nodes just as running > on the same machine. > > I see several advantages over MySQL Cluster to running this > way - less number of dedicated MySQL nodes (no Admin, > SQL nodes, etc.), it integrates into an existing RHCS > arrangement, and, of course, cheaper due to not purchasing > MySQL Cluster. > > There are several disadvantages, such as no query caching > and it's not all in-RAM (speed-wise, although not committing > to disk that often is another issue...). > > Does that explain what I was trying to get across a bit > better? I still don't think I'm entirely off my rocker, > but I've done so before :) > > -Brenton Rothchild > > > gwood@xxxxxxxxxxxxxx wrote: >>> Anyone feel free to correct me, but I was just doing some >>> reading on active-active MySQL + GFS last night, and >>> I think such an arrangement might be possible to a degree. >> >> http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-overview.html >> >> "MySQL Cluster is a technology which enables clustering of in-memory >> databases in a share-nothing system." >> >> So I'm not sure what you're hoping to achieve... The on disk storage >> needs >> to be unique to each machine - and the data needs to all fit into >> memory. >> >> Unless I'm missing something? >> >> -- >> >> Linux-cluster@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/linux-cluster > > -- > > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > -- Omer Faruk Sen http://www.faruk.net -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
