Mysql Gone Away when i do a Drush Update ....

cannot reproduce this. try disabling your contrib modules one by one.

No feedback. Re-open with more information if needed.

Here's some more information. If possible, I'd like to rule out the possibility that this is a Drush problem. Does it make sense that it would take so long to get to the "No database updates required" line? It's taking over a minute. I'm assuming MySQL is simply timing out because things are taking too long.

colan@somewhere% drush @site-alias --verbose --debug updb
[bootstrap] Drush bootstrap phase : _drush_bootstrap_drupal_root()           [0.29 sec, 2.78 MB]
[notice]    Initialized Drupal 6.19 root directory at /path/to/drupal        [0.33 sec, 3.44 MB]
[bootstrap] Drush bootstrap phase : _drush_bootstrap_drupal_site()           [0.44 sec, 3.44 MB]
[notice]    Initialized Drupal site drupal.example.com at drupal.example.com [0.76 sec, 3.49 MB]
[bootstrap] Found command: updatedb (commandfile=core)                       [0.87 sec, 3.51 MB]
[bootstrap] Drush bootstrap phase : _drush_bootstrap_drupal_configuration()  [0.88 sec, 3.64 MB]
[bootstrap] Drush bootstrap phase : _drush_bootstrap_drupal_database()       [1.21 sec, 7.34 MB]
[bootstrap] Successfully connected to the Drupal database.                   [1.21 sec, 7.34 MB]
[bootstrap] Drush bootstrap phase : _drush_bootstrap_drupal_full()           [1.23 sec, 7.55 MB]
[bootstrap] Drush bootstrap phase : _drush_bootstrap_drupal_login()          [2.64 sec, 29.2 MB]
[success]   No database updates required                                     [69.42 sec, 33.84 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.42 sec, 33.79 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.43 sec, 33.81 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.43 sec, 33.81 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.43 sec, 33.81 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.43 sec, 33.81 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.44 sec, 33.81 MB]
[bootstrap] Including /usr/share/drush/commands/core/clear.cache.inc         [69.44 sec, 33.81 MB]
Calling call_user_func(drupal_flush_all_caches)
[error]     WD php: MySQL server has gone away
query: UPDATE variable SET value = 's:20:\"abc123\";'
       WHERE name = 'css_js_query_string' in /path/to/drupal/includes/bootstrap.inc on line 609.
                                                                             [69.46 sec, 33.86 MB]

Never mind. I'm getting this from my browser too. Sorry!

I'm getting similar error messages. I'm reopening, but that may not be appropriate. I want to add a detail nobody has mentioned though: I get screens and screens of errror output when I run drush up, but if I run drush upc and then run drush updatedb, I do not get any errors. I'm a fairly new drush user, but in 4-5 upgrades over 3 different sites, this has always been the case. I have never had drush up run successfully, and aside from errors on my end (config errors), I have never had the drush upc -> drush updatedb combo fail.

I assume this is likely some server config issue, but don't even know where to start for debugging this. Open to idea!

For what it's worth, here's some ouptup. In this last update, the initial errors scrolled off the screen in my SSH session, but what's left looks like this

null\";b:1;s:9:\"serialize\";b:1;}s:8:\"required\";a:4:{s:4:\"type\";s:3:\"int\";s:4:\"size\";s:4:\"tiny\";s:8:\"not
null\";b:1;s:7:\"default\";i:0;}s:8:\"multiple\";a:4:{s:4:\"type\";s:3:\"int\";s:4:\"size\";s:4:\"tiny\";s:8:\"not
null\";b:1;s:7:\"default\";i:0;}s:10:\"db_storage\";a:4:{s:4:\"type\";s:3:\"int\";s:4:\"size\";s:4:\"tiny\";s:8:\"not
null\";b:1;s:7:\"default\";i:1;}s:6:\"module\";a:4:{s:4:\"type\";s:7:\"varchar\";s:6:\"length\";i:127;s:8:\"not
null\";b:1;s:7:\"default\";s:0:\"\";}s:10:\"db_columns\";a:4:{s:4:\"type\";s:4:\"text\";s:4:\"size\";s:6:\"medium\";s:8:\"not
null\";b:1;s:9:\"serialize\";b:1;}s:6:\"active\";a:4:{s:4:\"type\";s:3:\"int\";s:4:\"size\";s:4:\"tiny\";s:8:\"not
null\";b:1;s:7:\"default\";i:0;}s:6:\"locked\";a:4:{s:4:\"type\";s:3:\"int\";s:4:\"size\";s:4:\"tiny\";s:8:\"not

For many many screenfuls - just scrolling and scrolling by. Then I suppose the MySQL server died as it switches to this (anonymized paths b/c I don't want to post too much info on server config).

null\";b:1;}}s:11:\"primary
key\";a:2:{i:0;s:3:\"rid\";i:1;s:4:\"type\";}s:6:\"module\";s:14:\"better_formats\";s:4:\"name\";s:23:\"better_formats_defaults\";}}',
created = 1285696488, expire = 0, headers = '', serialized = 1 WHERE cid = 'schema' in /path/to/domainroot.tld/includes/cache.inc on line 109.
MySQL server has gone away                                                                                                                                                                              [error]
query: TRUNCATE TABLE cache_views in /path/to/domainroot.tld/includes/cache.inc on line 172.
MySQL server has gone away                                                                                                                                                                              [error]
query: SELECT COUNT(*) FROM node_type WHERE type = 'image' in /path/to/domainroot.tld/modules/node/node.module on line 487.
MySQL server has gone away                                                                                                                                                                              [error]
query: INSERT INTO node_type (type, name, module, has_title, title_label, has_body, body_label, description, help, min_word_count, custom, modified, locked, orig_type) VALUES ('image',
'Image', 'image', 1, 'Title', 1, 'Body', 'An image (with thumbnail). This is ideal for publishing photographs or screenshots.', '', 0,
0, 0, 1, 'image') in /path/to/domainroot.tld/modules/node/node.module on line 505.
MySQL server has gone away      

I eventually killed it with CTRL-C and ran drush updatedb with no issues

Forgot to change status. Sorry

After playing around with settings for many hours, here's what finally worked:

In my.cnf:

-wait_timeout = 15
+wait_timeout = 120

In php.ini drush.ini:

-max_execution_time = 30
+max_execution_time = 120

Both the PHP side *and* the MySQL side need to have really high timeouts because that Drush command takes over a minute to complete (at least in my case). So setting them both to two (2) minutes allows it to finish. Run your drush command as I did, above, and note the number of seconds. Set both of the timeouts to be higher than that.

Glad this cleared up your problem.

That makes sense:

I also have
wait_timeout 20

Unfortunately I don't have adequate permissions to change the wait_timeout on my server, but I can do a simple test on a simple install with few modules and verify that this is the problem. If I wait at the y/n prompt, it times out and dies. If I don't, it doesn't. On more complicated installs with more modules and large updates requiring backing up things like Views and so on, I'm of course a lot more likely to timeout.

The MySQL manual suggests two solutions.

1. use mysql_ping () - that again poses a problem because it requires auto_reconnect to be active and in my case, it's off and, again, I don't have permissions to change it
2. Setting the wait_timeout in a session context with a query using SET SESSION wait_timeout=120 (SET command).

As it turns out, there is a module that lets you change this setting - http://drupal.org/project/drupal_tweaks

I'm not sure if that would get invoked during a drush run and in some ways, I don't necessarily want to change that in all contexts anyway. It would be nicer to be able to change it just in a drush context, but I'm not sure that's possible.

There's a Wordpress workaround that modifies Wordpress core - http://robsnotebook.com/wordpress-mysql-gone-away - but again that's a global solution.

So what do people think? Is it even possible to change the settings in a drush-only context?

You can change the settings for php.ini in a drush-specific way with #918468: drush.ini or php.ini? [Drush should use php.ini files in drush conf folders + some fixes for drush paths that contain spaces]. That has not been committed yet, but you could do the same thing by defining an alias. See #916438: exec() has been disabled for security reasons environment.inc:482 [warning] for an example of the alias you'd need.

There isn't any way that I know of to make mysql settings drush-only. Drush uses Drupal code to bootstrap the database, so probably not...

A little frustrating - because of access restrictions, it's hard for me to tell exactly, but it seems that installing the Drupal Tweaks module and setting the wait_timeout to 200 fixed this for me. We'll see if that's true, but I successfully ran drush with a 110 sec execution time and previously anything over 60 was crashing.

I'll have to track this over time, but since I was having close to a 100% failure and so far I am unable to generate a failure, I think this has worked.

Apologies for reopening but I think the fix here isn't a long term fix (though happy to be argued down!)

For D7 users the way that Drupal Tweaks (which is D6) does this is with a command like this:

db_query('SET wait_timeout = 600');

Where 600 is 600 seconds (10 minutes). If you are having a timing out drush command you'll need to add something like this is there to override before executing the batching process. You'll have to set this high enough to cover what ever operation it is you are running and is quite an intrusive override of the settings of the mysql db server.

I wonder instead if the drush batch operation should not be handling this in some way? I am using the views_data_export module to generate XML from a view with some 2000 nodes in it and this can take 5 or 6 minutes to run. The feed is generated correctly in the batches but when control passes back to the originating drush script the db connection has now timed out. Could something be added whereby the originating drush script process could keep its connection alive by pinging the db server every so often? I don't know how this would be achieved.

Changing status; this is not a support request, but a feature request. I'm not sure if it is within the scope of Drush to adjust the sql database timeout. Perhaps a documentation addition might be helpful. If anyone has a patch to contribute, it would be most welcome.

Is the problem just that the connection is stale? Rather than set a new db timeout (which would be impossible for drush to predict a reasonable amount before hand) is it possible to detect that this has happened and create a new connection?

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.