Xaprb

Stay curious!

Using Go’s auto-reconnecting MySQL client libraries

with 3 comments

I’ve been doing a little bit of programming in Go recently, and really enjoying it. It’s an awesome language with really solid libraries. It reminds me a lot of the .NET framework in that it’s well-thought-out, but the Go language itself is a lot smaller, less formal, and a lot more expressive than I ever found C# to be. And that’s saying a lot — C# was my previous favorite language, along with the occasional Java, C++, Python, JavaScript, and — gasp — Visual Basic 6. Go beats them all.

But I digress. I’m writing Go applications that talk to MySQL. Some of them talk to the database in read-only ways, and I just wanted to share this neat little nugget about the MyMySQL client libraries (pure-Go implementation; not a wrapper around a C library). One of its features, which you can enable optionally, is autorc. This stands for auto-reconnect to the server. It’s done very smartly. In fact, you don’t even have to connect at all; you just query the server, and the connection either opens or reopens. I’ve tested it and it’s really working well.

This has removed a large pile of smelly code from my application. It’s awesome. That’s all, folks!

Written by Xaprb

November 1st, 2012 at 7:53 pm

Posted in SQL

3 Responses to 'Using Go’s auto-reconnecting MySQL client libraries'

Subscribe to comments with RSS

  1. Hi Baron!

    I’m not a big fan of auto-reconnect in drivers – I think it encourages people to neglect important aspects of connection state that are lost when connections die. I haven’t looked into the Go library at all, but it’s hard for me to imagine that the Go driver solves these problems. I wrote a blog post about this a while back related to Connector/J:

    http://mysqlblog.fivefarmers.com/2010/07/05/do-you-really-want-autoreconnect-to-silently-reconnect/

    Maybe there’s nothing “silent” about Go’s reconnect functionality, and developers are forced to think through the consequences of failed connections. My experience has been that reconnect capability enables such problems to be ignored.

    Todd Farmer

    2 Nov 12 at 12:39 am

  2. Todd,

    I agree in general. The work I’m doing is read-only polling the server for information. There was a suggestion to enable auto-reconnect by default in Percona Toolkit a while ago, and my response was an unequivocal no because a lot of the work it does is quite sensitive to connection state.

    I’ll have to look into the auto-reconnect in the Go driver if I see a situation where I’d like to use it for something that is stateful or not read-only. It does have some facilities for determining if a transaction is valid, but I haven’t examined that deeply.

    Xaprb

    2 Nov 12 at 8:57 am

  3. Valerie

    15 Dec 12 at 11:09 am

Leave a Reply