2

I have a development server set up in my drush aliases as @dev, and a UAT server set up as @uat. I can successfully execute drush commands locally on both servers, and I can execute remote commands from UAT to the development server (e.g. drush @dev cc all or drush @dev upc or whatever). However, when from the UAT server I execute

drush sql-sync @uat @dev

it appears to work, but when I first make a change on UAT and then sync and then check the same page on dev is has not changed. I have tried drush @dev cc all afterward to make sure there is no caching problem, but this doesn't help.

What could I be missing? Or what could be failing? How can I troubleshoot this?

UPDATE (corrected): If I log into @dev and execute the same command (in other words, having @dev pull data from @uat rather than having @uat push data to @dev) it works. But I'd still like to get it working when executed from @uat.

Improve this question

5 Answers 5

Reset to default
9

There's not enough here to tell what's wrong, but there are a couple of things you can do to isolate the problem. Start with drush @uat sql-conf and drush @dev sql-conf; this is what Drush will use to look up the database records for the two sites. If one of these fails to print the right information, that could cause sql-sync to fail. Next, try drush sa --with-db @uat and again for @dev, and see if the database record matches what you saw with sql-conf. If, for example, you copied a database record into your @dev alias and specified the wrong database (one different than the one specified in settings.php), then sql-sync might be successfully copying your production database to some other db on the dev machine.

If neither of these things work, you can try adding first -v (verbose output) and then -d (debug mode -- really a lot of output) and see if there is anything there that might help you find the problem.

Update: Did you make a typo in your update? drush sql-sync @dev @uat pushes dev to uat, which seems like the opposite operation. If drush sql-sync @uat @dev works on dev and not on uat, I would recommend carefully comparing your alias files on the two machines and see if there are any differences. Especially check your 'databases' record in your alias definition, if you have any, and run the diagnostic tests I recommend above. As a workaround, from uat you could run drush @dev sql-sync @uat @dev, which would remotely run drush sql-sync @uat @dev on the dev machine.

Improve this answer
4
  • Yes, sorry. I corrected the error in my update now.
    – iconoclast
    Oct 19, 2012 at 17:28
  • I'll try your suggestions soon...
    – iconoclast
    Oct 19, 2012 at 17:28
  • You're right, there were errors in the aliases file on @dev... all fixed now.
    – iconoclast
    Oct 19, 2012 at 20:39
  • To add to Greg's answer, I also ran into this just last night when the path to drush on my server had changed. e.g. from /usr/bin/drush to /usr/local/bin/drush - I found it, however, using his sql-conf trick. Thanks Greg!
    – webkenny
    Jul 28, 2013 at 11:55
2

I had the same problem. My solution was to add the ending '--no-cache'

drush sql-sync @dev @local --no-cache

If you don't do that, drush takes the last saved sql-dump.

Cheers Stefan

Improve this answer
0

I've solved my problem with sql-sync after I updated the drush version on my localhost. It was 5.7 on localhost and 6.0-rc4 on server. After update the drush version on localhost is 7.0-dev. sql-sync works well!

Improve this answer
0

I had the same weird problem and after cleared @dev cache it worked.

Improve this answer
0

When I encountered this issue, I used verbosity (--verbose) to find that I was getting a MYSQL error 2013 "Lost connection to MySQL server during query" in the last stage of the synch.

Turns out my packet size was too small so my end couldn't finish the job.

That is not necessarily meant to be a double entendre.

So I edited the my.cnf (mine was in /etc/mysql) and cranked it from 16M to 128M.

Also, had to use --no-cache.

Improve this answer

Your Answer

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

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