Forums

I don't get this. Can you please look into this ASAP?

This error is typically caused by MySQL closing the connection due to idleness, although it can also be caused by intermediate network equipment closing the connection. For example, overly aggressive firewalls and load balancers can sometimes kill off connections after a relatively short idle period.

Is this a web application, a scheduled script, something you're running from the command-line or a long-running daemon? Particularly in web applications a connection pool is often used, to cache database connections for performance reasons. If you're using a pool, be aware that you'll need to test the connection as part of removing it from the pool. You can use the MySQL ping function for this - see this blog post for some more detail.

If this error occurs on an actively used connections (i.e. where there's been a successful operation less than,  say, 60 seconds before) then that's definitely something to let the admins know about. Please indicate the frequency with which it occurs as well. If, however, it's an occasional thing then it's something you may just have to deal with in your code.

Keep your transactions short because a connection close midway through a transaction will cause an implicit rollback and your changes will be lost. Always test a potentially idle connection (especially one that might have been sitting in a connection pool for hours) just before starting a new transaction and reconnect it or make a new connection if necessary.

EDIT

By the way, you might wonder why MySQLdb doesn't just automatically reconnect for you without all this rubbish. The reason is that if you have a disconnect, you need to be aware of it because any pending transactions may have not been committed. In fact, if the disconnection happens at the point you commit your transaction, I'm not aware of any way to tell whether your transaction was committed or not. Hence, libraries can't just quietly reconnect for you because it may hide underlying issues. This post has some more discussion (although it's targetted at Java users, the principles remain the same).

Of course, as long as you keep your transactions short, the chance of a disconnection at commit time should be very low since the connection should never be idle - that would only occur due to loss of network connectivity or similar. If your application has critical reliability considerations, however (such as tracking account balances) then I suggest you always update a separate audit table with every transaction, ensuring each entry has a unique ID. The database guarantees that transactions will be atomic even in the face of connectivity issues or similar, so the existence of absence of a unique ID in the audit table indicates whether your transaction succeeded or not. For the vast majority of applications, however, this sort of complexity is total overkill.

Yup, as Cartroo said. This is not a PythonAnywhere problem. This is a problem with your usage of MySQLdb. If you want a code example which shows you how to manage connections in MySQLdb then check this out: Managing MySQLdb connections.

@hansel: Not sure if it's worth noting on that page but it could have surprising effects if code relies on transactionality. Consider:

UPDATE savings_account SET balance=balancer-100 WHERE user_id=?

... Code pauses for some reason - maybe it's waiting for a lock on something else which is churning for some reason. While it's hung the MySQL connection drops. This causes the transaction above to be rolled back. Then the code becomes unblocked and continues:

UPDATE current_account SET balance=balance+100 WHERE user_id=?

This code raises an exception, but the wrapper in that code snippet handles it and silently retries the statement on a fresh connection. Now it succeeds, but the programmer, who was probably relying on the transaction to guarantee that either both or neither statement was executed, has just given someone £100 free in their current account.

I'm not suggesting that a handy tips page like that is the place to document the full implications of the effect that losing connctions has on transactions and similar MySQL concepts, but a short note to be aware of it might save someone some hair-pulling one day, you never know.

Thanks for your suggestions. But in this case the web site is just SELECTing from a table. There are no UPDATE's.

Ah well, if you only need read access then more or less anything should be pretty safe (unless you have a critical need to get consistent data from multiple tables and can't, for some reason, do a join - that sounds like a pretty obscure thing to do, though).

Hi all, we now have a help page on managing mysql connections, which includes info on the mysql server has gone away error 2006