The command "sql-dump --gzip" works spectacularly well, but it would be even more spectacular if sql-sync could use this option as well. If so, it wouldn't be necessary to keep large uncompressed DB dumps on the file system for syncing purposes. In fact, it would be doubleplusgood because disk space would be saved on both the source and destination sides.

Other reasons:

  • On some systems, /tmp can be rather small.
  • Some DBs are so large that they may not be able to be dumped uncompressed at all.

Comments

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (won't fix)

In general, seems like a bad idea as that would ruin the rsync speedup. But perhaps we should do this when we know that there is no file to sync with on the target side. Open to suggestions.

greg.1.anderson’s picture

greg.1.anderson commented

See also: http://groups.drupal.org/node/113789

sdeziel’s picture

sdeziel commented

I agree that when the destination contains an uncompressed SQL dump the rsync speed would suffer but if the destination has no SQL dump or a gzipped one the transfer speed shouldn't be impacted noticeably. I also think that people using the eventual --gzip option will probably not face very often the case where a gzipped version exists on the source while an uncompressed SQL is on the destination. IMHO, this option would benefit to people with small /tmp and big DB.

geerlingguy’s picture

geerlingguy commented
Status: Closed (won't fix) » Active

I'd like to open this back up and ask if we could get this feature again. I'm trying to sync a multi-GB database, and I've had to do it from a few different computers/connections now, and it's annoying to have to do an sql-dump, then sync the resulting file via ssh/scp, then import locally, rather than just use sql-sync to get a gzip file.

The uncached sql file is over 4GB, so it takes a pretty hefty chunk of disk space on both the server and client machine (on my MacBook Air, it's cutting storage space pretty close; soon I won't be able to get the file via sql-sync at all). It also takes a ton of time over slower internet connections to get that file (even with rsync speedups). Compressed, the database is only a few hundred MB.

When I try simply passing the --gzip option to sql-sync, the resulting file format is a little off, resulting in an error like:

mv: cannot stat `~/backups/drush-sql-sync-dump.sql.gz-1347382253': No such file or directory
rsync: link_stat "~/backups/drush-sql-sync-dump.sql.gz" failed: No such file or directory (2)
greg.1.anderson’s picture

greg.1.anderson commented

Related blog post: http://www.agileapproach.com/blog-entry/simplify-importing-production-da...

greg.1.anderson’s picture

greg.1.anderson commented
Version: » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

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.