It’s worth noting the version of MySQL that comes installed with Acquia Dev Desktop 2 (5.6.41-84.1) is still 32-bit (unlike PHP which is now 64-bit). Recently I was testing with a particularly large database and found it kept crashing with things like:
‘MySQL server has gone away’
Lost connection to MySQL server at ‘reading authorization packet’
Intensive operations such as Drupal-to-Drupal migration tended to trigger this.
I used MySQLTuner but the changes made little difference so then it occurred to me the 32-bit version simply wasn’t up to it, so I installed the latest 64-bit mariadb from homebrew instead and moved the relevant databases over to that (I have mariadb running on port 3306 and Dev Desktop’s MySQL on it’s default 33067).
So far it’s been stable.
Updated Tue 8 Jan 2019
Symptom: drush updb hangs
drush updb is hanging, first, run it with the
--verbose script to see exactly what’s going on – that will show you the MySQL connections. (It turned out in my case Drush was connecting to the wrong database).
Symptom: drush connects to wrong database
- Try starting the terminal connection via DevDesktop (the icon top right) and see if that makes a difference
- Double the database connection details in the appropriate
loc_ file in ~/.acquia/DevDesktop/DrupalSettings/
- Check your
drush status output
- Check what happens if you run
- Try installing the latest Drush (
composer require drush/drush) rather than relying on the version that comes with DevDesktop (at time of writing that’s 8.1.7, whereas Drush is now up to 9.5.2)
My situation: I have two MySQL installations running, the 32-bit DevDesktop supplied version, and a 64-bit mariadb (for a very large site where I was experiencing connection timeouts). They are on different ports. I had a site where ordinary drush commands and drush sqlc connection went to the correct MySQL server but
drush updb used the wrong one (confirmed using the
--verbose option – in fact it was connecting to a database with a different name entirely.
I couldn’t figure out what was going on, so I upgraded from Drush 8 to 9 and that fixed it immediately.
Symptom: large Drupal 7 site where cache is extremely slow or fails to clear…
drush cc all
…and eventually PHP runs out of memory (“cannot allocate”).
Check Drush is using the correct version of PHP, it may not be – use
drush status or, more simply:
$ which drush
$ vim /Applications/DevDesktop/tools/drush
# edit the PHP version: [ -z "$PHP_ID" ] && PHP_ID=php7_1