Brian "Krow" Aker's Idle Thoughts - Proxy, Proxy, on the Wall, who is the fairest of them all...

SQL Relay, http://sqlrelay.sourceforge.net/

Have used it several years before MySQL came into existence.

Added yours :)

Mmm, yes, I keep meaning to arrange a conversation with you about this.

It pays the bills.

http://myosotis.continuent.org/HomePage

This one is kind of cute. It's not as flexible as mysql-proxy & friends, but it masquerades as a MySQL or PostgreSQL frontend and connects to (non-MySQL/Postgres) backend servers via JDBC.

I, for one, wish to partake in this harvest of information.

But I still try to stay informed... a little.

Besides, you never know when the opportunity to do something different may arise!

I was really disappointed in the MySQL Proxy talk at the conference, so started working on my own... In Erlang (my latest obsession/toy).

It's still vapourware, though I do have it working on my laptop. Eventually I'll check the code in here:

http://code.google.com/p/merp-mysql-proxy/

I doubt this should really make your list, but maybe worth checking on in like a month.

I'm referring to the Tutorial Day (6-hour) talk.

My primary gripe was what was covered; maybe the target audience was too wide. A lot of time was spent talking about Lua (rather than MySQL Proxy, which I was there to learn about), and I expected a lot more technical details of how the Proxy was implemented. I guess if it was split into two talks ("Writing Lua plugins for MySQL Proxy" and "MySQL Proxy Low-Level Details/Implementation") I would have skipped the former and definitely gone to the latter.

The rest of my gripes are not about the talk but about the implementation of the Proxy itself.

The Lua support seems tacked on and poorly thought out. What is exported from the C layer to the Lua layer is incredibly poorly documented. Basically you have to read through all the samples or the C code to try to understand what's exported to Lua and how it modifies the behaviour of the server. If I have to know C and read through a bunch of C code to figure out how to write the plugin, why not just make the plugin interface in C? I don't see the advantage in the Lua support.

The lack of support for chaining plugins is pretty lame (you can only load one lua script/plugin per proxy?).

You have to restart the proxy to make any config changes.

I saw no way for plugins to spin off a thread or do async. i/o (maybe i don't know enough about Lua).

I didn't know about spock proxy until seeing your post. Their differences from Proxy are also in line with some of my gripes and goals (No Lua/Client Auth/Dynamic Pool/etc). If I wasn't obsessed with Erlang at the moment I'd definitely run straight over there and start contributing. I want to see how Erlang TCP services perform and especially how much of an impact it'll have as an observer/logging/statistics 'thing' - theoretically you could do some heavy logging and data analysis with very little impact on the Proxy throughput. If my experiment fails it'll at least be interesting, and I'll definitely turn to Spock next; it seems to me that they are on the right track (for my needs).

Proximo.

I don't think anybody has actually played with it besides me, and I wrote it, so I don't think I count. ;-)

It's quite functional and works well for what it does, but it's pure Perl at this point and isn't extremely fast. I think the MySQL Proxy approach of having a C core is a good one, but I ran into the same issues as the above poster - couldn't figure out how to do what I wanted. (Which is mostly documentation and lack of Lua knowledge, I imagine.)

Also, I'm a sucker for Perl. All those years working on Perlbal, the same sort of approach seems like it would work really well for MySQL as well!

Beautiful list, thanks a lot

(I wish I could use openid to leave comments)

Yep, I've fixed that for the installation of LJ.Rossia.org
but never proposed the change into upstream.

Since the change is quite easy (speaking of technical part)
I suppose they have some social/political issues with it