mysql-proxy-discuss team mailing list archive

[nick loeve <trickie@xxxxxxxxx>]

Hi!

I am going to outline the future direction of the funnel plugin,
partly to kickstart discussions for the hackathon in Hamburg (in the
architecture areas I am looking at anyway).

The code in my branch on launchpad is kind of a 'feature complete
prototype'. We are using it internally at Hyves (where I work) for a
variety of purposes. Apart from any major failings we have here, the
current branch will probably not get any more functionality or
changes. I don't assume anyone else is actively using the plugin, but
it is usable for the original use case outlined in the blueprint in
launchpad (a proxy instance per mysqld in a load balanced replication
slave farm).

I have started a new branch (not yet on launchpad) that will implement
the feature set of the current plugin, plus some longer term goals,
such as multiple backends, dynamic add/remove of backends, query load
balancing and support for multiple users/databases. I would also like
a cleaner code structure than I have now and I intend to get the code
more closely aligned with the rest of the project's code, for instance
creating patches for the connection pool used by the proxy plugin
instead of implementing a completely separate pool (as it is now in
the funnel).

The goals (in no particular order here) include:

 * backlog support in the chassis core
 * changes to the protocol state machine to make the backlog usable
 * enforceable connection size limits to a connection pool, per user/db
 * dynamically add/remove a backend
 * optional scripting layer (we do not use LUA in the funnel plugin,
and it would be nice to make LUA support a compile time option)
 * advanced statistics on the backends, connection pools, chassis as a whole etc

Some of these things (backlog, state machine changes) are already
present in the current prototype, but they are probably not done
'correctly' and are mixed into my branch with other changes. I would
like to get feedback on whether the above types of things would be
wanted/needed/acceptable in the chassis/mysql-proto core, and if
anyone has ideas on how they are best implemented.

My immediate goals:

 * backlog in the chassis core
 * hooks for the backend 'objects' and connection pool  'objects'
whereby a plugin can influence their behavior. This may be something
like callbacks when adding or removing or requesting current state. I
see this as essential for the goal of dynamically adding/removing
backends and limiting connection pool size.

Obviously the above changes should have no impact, performance or
otherwise on plugins that do not use them.

That was just a quick brain dump from what we have been talking about
internally here at work... any further points or discussion would be
appreciated.

Cheers

-- 
Nick Loeve