[Linux-cluster] mysql and redhat cluster suite?

[Omer Faruk Sen]

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 at dragonhold.org 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 mailing list
>> Linux-cluster at redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-cluster
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>


-- 
Omer Faruk Sen
http://www.faruk.net