Announce: LBPool 1.0 beta1 (Load Balancing JDBC Connection Pool)

Kevin Burton · *nix forums addict Joined: 06 May 2005 Posts: 61

There was a thread before about this... this is much better than connector
J's load balancing.

You can take machines out of production, add thhem back in, it's MySQL slave
aware, etc

On 7/19/06, Christopher G. Stach II <cgs@ldsys.net> wrote:

Christopher G. Stach II · *nix forums beginner Joined: 19 Jul 2006 Posts: 1

Kevin Burton wrote:

Kevin Burton · *nix forums addict Joined: 06 May 2005 Posts: 61

Hey Gang.

I wanted to get this out on the list and facilitate some feedback.

http://www.feedblog.org/2006/07/announce_lbpool.html

I CC'd both lists because this might be of interest to the larger MySQL
community as the techniques I used here could be implemented in other
languages.

==========

The lbpool project provides a load balancing JDBC driver for use with DB
connection pools. It wraps a normal JDBC driver providing reconnect
semantics in the event of additional hardware availability, partial system
failure, or uneven load distribution. It also evenly distributes all new
connections among slave DB servers in a given pool. Each time connect() is
called it will attempt to use the best server with the least system load.

The biggest scalability issue with large applications that are mostly READ
bound is the number of transactions per second that the disks in your
cluster can handle. You can generally solve this in two ways.

1. Buy bigger and faster disks with expensive RAID controllers.
2. Buy CHEAP hardware on CHEAP disks but lots of machines.

We prefer the cheap hardware approach and lbpool allows you to do this.

Even if you *did* manage to use cheap hardware most load balancing hardware
is expensive, requires a redundant balancer (if it were to fail), and seldom
has native support for MySQL.

The lbpool driver addresses all these needs.

The original solution was designed for use within MySQL replication
clusters. This generally involves a master server handling all writes with a
series of slaves which handle all reads. In this situation we could have
hundreds of slaves and lbpool would load balance queries among the boxes. If
you need more read performance just buy more boxes.

If any of them fail it won't hurt your application because lbpool will
simply block for a few seconds and move your queries over to a new
production server.

While currently designed for MySQL this could easily be updated to support
PostgresQL or any other DB that supports replication.

--
Founder/CEO Tailrank.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Blog: feedblog.org

Google