drush sql import

I see. I was in fact able to confirm that the following works:

sudo -u postgres `drush sql connect` < tmp.sql

This is equivalent to drush sql import, but the syntax is a little odd. I also was able to do this:

echo "select * from users;" | sudo -u postgres `drush sql connect`

This is equivalent to drush sql query, and of course `drush sql connect` by itself is equivalent to drush sql cli. In any event, I'm happy enough to use the `drush sql connect` workaround in place of drush import.

I'll fiddle with the db_url settings; I'm reluctant to make an external pointer to my production site, though. Maybe I could make a dev site on the remote machine, and point to that. Of course, at that point I'd have to do a remote production -> dev update before doing the remote sync. I'll experiment a bit and see what I come up with.

Thank you for your thoughts and comments.

Thanks,

- Greg

This reply is FYI only; comments are welcome, but no action is necessary.

The RO user would work well unless you made a mistake and logged in through the "shadow" configuration with an admin account. I'm guessing that drupal is not designed to allow multiple drupal instances to share the same password (with the same db prefix), so if someone accidentally got into a situation where two people were writing to the same database from different instances, corruption would likely result. Over the next year I'm going to deploy half a dozen drupal sites, a couple of which will have multiple admins of varying skill levels. Since I will only be peripherally involved with some of these sites, I want to make sure that the configuration is easy to back up and not dangerous.

I looked at a number of possible solutions last night and came up with two that I thought were acceptable.

• Set up the "shadow" site under a name that does -not- resolve in DNS to this machine; then it will be possible to access the database via drush, but not via a web browser.
• Set up an override theme in the settings.php of the shadow site; remove all of the normal contents of the theme template and print only an "unavailable" message.

Under this configuration, I think I like the idea of using 'drush sql load' better than a dump / remote copy / import drush command. The advantage of drush sql load is that you can set up the parameters in advance, and then address the sites by name. The parameters for the later would be more complex, although it wouldn't be too bad, I suppose, if you presume that 'drush' is on the path and appropriately configured on the remote machine.

The next thing I'm going to work on is a drush command to put a site into maintenance mode (trivial), and perhaps another command to set the site theme (in case someone wanted to use 'theme locking' to prevent admin access to the destination site during sql load or merge).

Thanks,

- Greg

Okay; for now I will use "drush eval" instead of making a bunch of little drush commands that wrap a single variable_set.

Thanks!

- Greg

@chris,

There is no point in subscribing to this thread; it is closed. There will be no 'sql import' command. See the thread on drush sql sync for the latest thread on pushing sites cross-machine.

- Greg

@anutaubu: FYI, I don't use sudo -u postgres to call drush any more; the problem with doing this is that you have to worry about the different access rights that the postgres user might have compared to the user you are logged in as. It's just not convenient. Instead, I make a file ".pgpass" in my home directory, and populate it as follows:

hostname:port:database:username:password

On my Ubuntu system, my file reads like this:

localhost:55432:*:www-data:mydatabaseuserpassword

When you do this, you can then conveniently call drush directly, just as moshe shows in #10 above.

Use backticks:

`drush sql connect` < FILE

drush sql-connect will print out the command to connect to your sql client. Wrapping this in backticks executes the command.

drush sql-cli < FILE should also work.

See also #935796: How to restore a database dump with drush..