Re: Design of a Client-side MySQL Java Load Balancer
image ? you're modifying row n, node x wants to modify it, you need a rollback segment for that ! which value node x will read. i'm considering every DML is a transaction in an RDBMS, so when you say that you don't use transactions, you miss something. about load balancing, how do you track long operations and decide to migrate a transaction to another node ? have you any benchmarks with say 4 nodes , 100 transactions terminating in different times with a a protocol making a first node crash, so a seconf, so a restart of one of them, during the 100 transactions, and each node load ? Selon Kevin Burton <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > >Hi, > >i think that client load-balacer are more Dispatchers than real load > balancer. > > > >load balancing in the database side takes care to number of connections, but > >also node load. So thisis more real. But this issue is difficult. > > > > > > > No... you're making assumptions. With the two-phase protocol I > developed the nodes cooperate and distribute load and connections. They > also handle failover. > > Simply put I can do a better job than hardware balancers because I > already KNOW what MySQL can do. Most load balancers are dumb. > > >even for oracle with 9iRAC and 10gRAC, load balancing is not completely > >controled. > > > >you speak abot load balancing and introduce also the failover notion, which > >isnot a load balancing concept. Fail over is difficult because controling it > >implies that every node must have the image before of every transaction. > > > > > > > Image? > > Failover isn't a load balancing concept? Not according to our hardware > vendor :) > > >With cache fusion, ora > > > > cle RAC gives a solution, but assumes failover only fo select > statements. All DML statements are lost if a > > node is lost. > > The DML situation here is a tough one. For SELECTS I have no problem > with failover. For DML I would have no problem unless you're in a > transaction. > > We don't use transaction and I think they're evil anyway. > > Kevin > > -- > > > Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. > See irc.freenode.net #rojo if you want to chat. > > Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html > >Kevin A. Burton, Location - San Francisco, CA > AIM/YIM - sfburtonator, Web - http://peerfear.org/ > GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Design of a Client-side MySQL Java Load Balancer
[EMAIL PROTECTED] wrote: Hi, i think that client load-balacer are more Dispatchers than real load balancer. load balancing in the database side takes care to number of connections, but also node load. So thisis more real. But this issue is difficult. No... you're making assumptions. With the two-phase protocol I developed the nodes cooperate and distribute load and connections. They also handle failover. Simply put I can do a better job than hardware balancers because I already KNOW what MySQL can do. Most load balancers are dumb. even for oracle with 9iRAC and 10gRAC, load balancing is not completely controled. you speak abot load balancing and introduce also the failover notion, which isnot a load balancing concept. Fail over is difficult because controling it implies that every node must have the image before of every transaction. Image? Failover isn't a load balancing concept? Not according to our hardware vendor :) With cache fusion, ora > cle RAC gives a solution, but assumes failover only fo select statements. All DML statements are lost if a > node is lost. The DML situation here is a tough one. For SELECTS I have no problem with failover. For DML I would have no problem unless you're in a transaction. We don't use transaction and I think they're evil anyway. Kevin -- Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. See irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Design of a Client-side MySQL Java Load Balancer
Hi, i think that client load-balacer are more Dispatchers than real load balancer. load balancing in the database side takes care to number of connections, but also node load. So thisis more real. But this issue is difficult. even for oracle with 9iRAC and 10gRAC, load balancing is not completely controled. you speak abot load balancing and introduce also the failover notion, which isnot a load balancing concept. Fail over is difficult because controling it implies that every node must have the image before of every transaction. With cache fusion, oracle RAC gives a solution, but assumes failover only for select statements. All DML statements are lost if a node is lost. The mysql concept of clustering is different from the oracle one. Will oracle shares all in memory, mysql clusters share nothing. I'm studing this now, so can't give you more details, but i think that in future versions, all RDMBS constructors will control the two concepts in the database side. Mathias Selon Kevin Burton <[EMAIL PROTECTED]>: > I'd love to get some feedback here: > > > MySQL currently falls down by not providing a solution to transparent > > MySQL load > > balancing. There are some hardware solutions but these are expensive and > > difficult to configure. Also none of them provide any information > > about the > > current state of your MySQL configuration. For example they can't handle > > transparent query failover if a MySQL box fails. They also can't > > disconnect and > > reconnect to another host if the load grows too high. > > > > To that end I think it makes a lot of sense to have a MySQL > > client-side load > > balancer. > > > > This area is difficult to implement. There are a log of design issues. > > Also the > > issues WRT distributed connection management start to make the problem > > difficult. > > > > The other day I had a bit of an epiphany on this topic. > > > > > http://peerfear.typepad.com/blog/2005/06/design_of_a_cli.html > > -- > > > Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. > See irc.freenode.net #rojo if you want to chat. > > Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html > >Kevin A. Burton, Location - San Francisco, CA > AIM/YIM - sfburtonator, Web - http://peerfear.org/ > GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Design of a Client-side MySQL Java Load Balancer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Burton wrote: > [EMAIL PROTECTED] wrote: > > >>Wouldn't it make better sense to build on the NDB protocol and keep >>the native messaging infrastructure than it would be to build a >>similar wrapper from scratch? I mean to use the NDB communications on >>top of regular MySQL > > > Biting off an NDB migration would be a LOT harder than implementing > slave load balancing. NDB shows promise but I just don't think its > there yet... > > Kevin > Kevin, Shawn, - From a _total_ client connectivity standpoint, NDB is probably a dead-end, as it's based on message-passing. What we want is to support both HA _and_ distribution/partitioning from a clients' perspective. Federated and partitioning on the server side are a useful tool, and would work for some situations, but other users are going to want/need partitioning and load distribution at the _application_ level, which I think is the problem Kevin's talking about. -Mark - -- Mark Matthews MySQL AB, Software Development Manager - Connectivity www.mysql.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCniQttvXNTca6JD8RAovMAJ43r0rHzQ63qk5UhOxD4MjRNhLZOwCgjKF3 B0S8uyjQocbK52hw13NPk3A= =aJUl -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Design of a Client-side MySQL Java Load Balancer
We have a client-side load balancer, as well as a central load balancer
for mySQL traffic. I've done many different models at a variety of
companies, all which still use the solutions. Building on top of the NDB
protocol would take a very long time to produce-a HA solution native to
mySQL, when other technologies already exist-free to do this for you.
For example use heartbeat from linux-ha.org for failover.
Now for client-side load balancing, memcache from danga.com has some
interesting ideas. DBI::Multiplex also has some interesting ideas.
One of the easiest solutions is to load a database definitions file on a
shared drive. Have an external program add or remove hosts from each
cluster of the shared definitions file. Then use a random algorithm to
pick a host from a list that is defined apart a cluster to connect to.
array ('mycluster' => array ( array ('host' => myhost1,
'db'=>'mydb',...), array ('host' => myhostN,));
If your algorithm is random enough and spread across enough servers, the
results coalesce into a even distribution among all the servers in a
list. Very basic, very easy to implement and works.
The monitor program, run out of cron-or something, can have logic of
what to keep in a pool or what to take out of a pool.
DVP
Dathan Vance Pattishall http://www.friendster.com
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 01, 2005 1:21 PM
> To: Kevin Burton
> Cc: [EMAIL PROTECTED]; mysql@lists.mysql.com
> Subject: Re: Design of a Client-side MySQL Java oad Balancer
>
> Kevin Burton <[EMAIL PROTECTED]> wrote on 06/01/2005 02:31:54 PM:
>
> > I'd love to get some feedback here:
> >
> > > MySQL currently falls down by not providing a solution to
> > > transparent MySQL load balancing. There are some hardware
> solutions
> > > but these are expensive
> and
> > > difficult to configure. Also none of them provide any information
> > > about the current state of your MySQL configuration. For example
> > > they can't
> handle
> > > transparent query failover if a MySQL box fails. They also can't
> > > disconnect and reconnect to another host if the load
> grows too high.
> > >
> > > To that end I think it makes a lot of sense to have a MySQL
> > > client-side load balancer.
> > >
> > > This area is difficult to implement. There are a log of
> design issues.
>
> > > Also the
> > > issues WRT distributed connection management start to make the
> > > problem difficult.
> > >
> > > The other day I had a bit of an epiphany on this topic.
> > >
> >
> >
> > http://peerfear.typepad.com/blog/2005/06/design_of_a_cli.html
> >
> > --
> >
> >
> > Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
> > See irc.freenode.net #rojo if you want to chat.
> >
> > Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
> >
> >Kevin A. Burton, Location - San Francisco, CA
> > AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG
> > fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
> >
> >
>
> Wouldn't it make better sense to build on the NDB protocol
> and keep the native messaging infrastructure than it would be
> to build a similar wrapper from scratch? I mean to use the
> NDB communications on top of regular MySQL servers to provide
> for failover, hotswaps, and client registration. Haven't they
> already solved some or most of your client registration and
> reconnection issues during the development of that tool?
> There is also the "Federated" database engine that allows for
> queries to be run across more than one server at a time (not
> only can a query include a table from another database on the
> same server but also from a table in a database hosted on a
> different server).
>
> I think that between the two of those projects you have
> 80-90% of the wrapper you will need to run a MySQL cluster in
> a HA environment. The biggest problem I see is to prevent
> data collisions between servers (users connected to different
> servers trying to update the same record at the same time on
> different servers). Part of the NDB code has to contain the
> necessary cross-server locking messaging. And Federated
> servers will also do the same (at least to some degree).
>
> If you can get a JDBC version working, that would be great
> but I think the best dev path would be to re-use what is
> already there as much as possible. I am not discouraging the
> effort as much as I am suggesting another body of work to
> consider (or incorporate) in your design.
>
> Shawn Green
> Database Administrator
> Unimin Corporation - Spruce Pine
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Design of a Client-side MySQL Java Load Balancer
[EMAIL PROTECTED] wrote: Wouldn't it make better sense to build on the NDB protocol and keep the native messaging infrastructure than it would be to build a similar wrapper from scratch? I mean to use the NDB communications on top of regular MySQL Biting off an NDB migration would be a LOT harder than implementing slave load balancing. NDB shows promise but I just don't think its there yet... Kevin -- Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. See irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Design of a Client-side MySQL Java Load Balancer
Kevin Burton <[EMAIL PROTECTED]> wrote on 06/01/2005 02:31:54 PM: > I'd love to get some feedback here: > > > MySQL currently falls down by not providing a solution to transparent > > MySQL load > > balancing. There are some hardware solutions but these are expensive and > > difficult to configure. Also none of them provide any information > > about the > > current state of your MySQL configuration. For example they can't handle > > transparent query failover if a MySQL box fails. They also can't > > disconnect and > > reconnect to another host if the load grows too high. > > > > To that end I think it makes a lot of sense to have a MySQL > > client-side load > > balancer. > > > > This area is difficult to implement. There are a log of design issues. > > Also the > > issues WRT distributed connection management start to make the problem > > difficult. > > > > The other day I had a bit of an epiphany on this topic. > > > > > http://peerfear.typepad.com/blog/2005/06/design_of_a_cli.html > > -- > > > Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. > See irc.freenode.net #rojo if you want to chat. > > Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html > >Kevin A. Burton, Location - San Francisco, CA > AIM/YIM - sfburtonator, Web - http://peerfear.org/ > GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 > > Wouldn't it make better sense to build on the NDB protocol and keep the native messaging infrastructure than it would be to build a similar wrapper from scratch? I mean to use the NDB communications on top of regular MySQL servers to provide for failover, hotswaps, and client registration. Haven't they already solved some or most of your client registration and reconnection issues during the development of that tool? There is also the "Federated" database engine that allows for queries to be run across more than one server at a time (not only can a query include a table from another database on the same server but also from a table in a database hosted on a different server). I think that between the two of those projects you have 80-90% of the wrapper you will need to run a MySQL cluster in a HA environment. The biggest problem I see is to prevent data collisions between servers (users connected to different servers trying to update the same record at the same time on different servers). Part of the NDB code has to contain the necessary cross-server locking messaging. And Federated servers will also do the same (at least to some degree). If you can get a JDBC version working, that would be great but I think the best dev path would be to re-use what is already there as much as possible. I am not discouraging the effort as much as I am suggesting another body of work to consider (or incorporate) in your design. Shawn Green Database Administrator Unimin Corporation - Spruce Pine
Design of a Client-side MySQL Java Load Balancer
I'd love to get some feedback here: MySQL currently falls down by not providing a solution to transparent MySQL load balancing. There are some hardware solutions but these are expensive and difficult to configure. Also none of them provide any information about the current state of your MySQL configuration. For example they can't handle transparent query failover if a MySQL box fails. They also can't disconnect and reconnect to another host if the load grows too high. To that end I think it makes a lot of sense to have a MySQL client-side load balancer. This area is difficult to implement. There are a log of design issues. Also the issues WRT distributed connection management start to make the problem difficult. The other day I had a bit of an epiphany on this topic. http://peerfear.typepad.com/blog/2005/06/design_of_a_cli.html -- Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. See irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
