// you’re reading...


Why I won’t use HandlerSocket in Production…

There is a ton of hype around HandlerSocket right now. It looks awesomely wonderfully fast, fun and useful… however, I suspect there’s another side to the story.

These are my notions gleaned from my limited knowledge and experimentation:

HandlerSocket has some great use cases, but from a DBA perspective, it is a dangerous toy.

1.) It allows software developers to slice through any MySQL security/ACL scheme you may have setup for corporate applications.
2.) Storing any administrative access level passwords in clear text is not an option in a Sarbanes-Oxley compliant environment.
3.) Disabling query cache to maintain consistent reads is not a huge issue, but sucks nonetheless if your environment leans on it (aka you’re not using memcached).
4.) ACID transactions managed at the developer level? You must work in a methodical and rigid, integrity conscious environment where the developers prefer to utilize stored procedures whenever possible and changes have an approval cycle. : – )
5.) I have to package and deploy my own build. Meh. Bothersome.
6.) To my knowledge, there’s no ‘read-only’ flag. (see below)
7.) I have not tested replication so I won’t comment.

However, if I could switch on a read-only flag, it would be highly desirable and a bit more secure. I guess I could leave the wr-port empty and see if that blocks writes. The performance appears to be unmatched. I guess I’ll stay tuned.

I encourage you to download and install HandlerSocket for your own experimentation:

Update: Apparently, you can indeed leave handlersocket_port_wr = [BLANK] which will effectively disable writes, although I have not tried this myself to see if we can force writes against the read port.


No comments for “Why I won’t use HandlerSocket in Production…”

Post a comment

Help support my site and buy a domain name at http://domainsemailhosting.com/