I'm trying to move a live Drupal 7.39 site to my local Acquia dev set up which installs Drupal 7.41.

I follow what I think is standard procedure, which is to get a clean install, copy my site's sites folder, and then upload the database and run the update script.

I'm using the drush command drush sql-drop -y && drush sqlc < dump.sql. The first part of the command runs, the database tables are dropped, but then I get a 1045 error (28000) for my database user.

What perplexes me, is that the first part of the call works, but it fails in the second part. The sql file is too large to import through phpmyadmin, and I'm really dumbfounded here.

Should I update the live site to 7.41 before migrating it? I don't want to do this because I don't want to do updates on the live site.

What is causing this issue? I think it's a conflict with the SQL settings in the settings.php file, but they match the database user and authentication but I don't know enough about the guts of drush to figure out how to fix this.


2 Answers 2


To reduce the possibility that the size of your database is what is causing your problem, I would try to use the Backup and Migrate module.

In doing so, you can exclude all sorts of tables (which might reduce the size tremendously), similar to what I described in my answer to the question about "How to get an import of a very large Drupal database working?".

PS: my answer to your 2nd question (= Should I update the live site to 7.41 before migrating it?) is No, because you should not have to update a live site to create a development environment. If you have a need for them to be at the same level (to start from), then rather do the opposite: have your local site start from 7.39, then sync your database, and if needed (only) then upgrade your local site to 7.41. You'd get the same result, without touching your live site, right?


So, this was solved by changing the order I did things in, updated DB first, and then copied the sites folder, and then finally ran the update script. From what it seems is that if you copy the codebase before migrating the database drush get confused about which credentials to use. This was an issue with earlier versions of drush Drush Mysql access errors with sqlc.

  • very handy to know and thank you Pierre. In this case I didn't want to mess with the configuration of the live site I was working on. I didn't have drush access to the remote server, so my hands were a little tied. Now that I have the site on my local machine, I'll take a look at the size of the dump file after clearing the caches. The sql file was 344 MB. FWIW, I believe my order of operations here had more to do with the issue.
    – nizz0k
    Dec 8, 2015 at 15:02
  • I can see that the "order" to do things is indeed another possible solution. And yes "now" adding backup & migrate may be considered as changing the config (which is why I often have that module in a live site installed already). BTW, this module sometimes also helped me to get around going from (eg) a mac dev envir to a live linux envir to get around issues encountered when not using this approach. Dec 8, 2015 at 15:17
  • I regularly use the backup and migrate module, I'm doing updates on a site I didn't build.
    – nizz0k
    Dec 8, 2015 at 15:18
  • Aha ... THAT is where it gets interesting ... That's where the site "audit" challenges come in the game ... but that's another story (question?) of course ... Good luck! Dec 8, 2015 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.