How do I use Drush correctly to restore a site via the arr command?

Question

I am having an issue with the Drush arr command working correctly. I use drush to backup an archive on a testing server and then move it to a live server, or vice versa when needed.

Here is a typical command I use for restore

drush arr --db-url=mysql://name:pass@localhost/mydb

The database credentials on the test server are different from the live server. When drush completes the restore process it does so correctly and then says "the database credentials are appended to the bottom of the settings.php file"

That's great, and it indeed appends the correct information about the database, but this never works.

drupal always tries to read the original database configuration that comes before the appended information.

So, I always have to open up an editor, open up the settings.php file, scroll down to the bottom, remove the appended information, then manually go back and change the config information.

This is a huge waste of time.

How do I use this command correctly to avoid that? I want to seamlessly be able to type the command and immediately start using the site without having to manually edit anything.

Also, given that the database config variable is an array, how do I just tell the settings.php file, via drush, to use one or the other? If I have config for a testing environment and a live environment, I simply want to tell it which one to use as needed.

EDIT:

I wanted to add some more information as to the errors I get as well as the settings.php information.

So, immediately after using the command above, this is the error I get on the server I am restoring to:

PDOException: SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost'
(using password: YES) in lock_may_be_available() (line 167 of 
/var/www/vhosts/domain.com/httpdocs/includes/lock.inc).

Here is what the settings.php file contains for the original db configuration:

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'mptest',
      'username' => 'root',
      'password' => 'mypass',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

Here is what is appended to the end of the settings.php file:

// Appended by drush archive-restore command.

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'driver' => 'mysql',
      'username' => 'name',
      'password' => 'pass',
      'port' => '',
      'host' => 'localhost',
      'database' => 'livedb',
    ),
  ),
);

This looks to be the same except that the sequence for the config is different than the original. Even so, I get the error as stated above. Could the config property sequence be causing this?

Answer 1

settings.php is just an executable php file, so it seems on the surface that there should be no reason for you to do the editing step described above as long as

a) you have not inserted anything in your settings.php file (like a 'return' statement) that halts execution before the end

and

b) the database information that Drush writes at the end of settings.php is the same as the database information you hand-edit into the normal location.

If you are doing the editing information because the database information on your testing server is DIFFERENT than the database information on your production server, then you would be better off using sql-sync to migrate your database from one to the other, and migrate your code with either drush rsync or a version control system such as git. By default, drush rsync will not transfer your settings.php file, so you can customize it in each location and not have to worry about it being overwritten. If you use a vcs, you could exclude settings.php e.g. by using a .gitignore file.

Finally, I should add that it is only viable to use sql-sync or archive-dump/restore to move a whole site from testing to production BEFORE you have user generated content. If you ever have users who create accounts, add content, post comments, etc., copying the whole site will overwrite all of that information. Usually, folks copy the database from live to test only, and copy only code from test to live. To move configuration, look into the features module, or drush ctools export bonus.

Update: archive-dump / archive-restore does support changing database specs, and seems to be working correctly per your use case described above. Note, however, that you said in your updated text that the two db records are the same, but in fact they have different database names. This, I expect, is as it should be; I further presume that the database info archive-restore is writing to the end of settings.php matches the info you pass in on the command line.