0

I want to use drush to run the migrate command to upgrade my drupal version 6 to 7 using Data Export Import module.

I have two site in different path.

How do I run drush migrate for the Testing website below. Drupal version is 6.

Main website

/domains/site.com/public_html

Testing website

/domains/site.com/public_html/testsite

1

To use Drush to more effectively migrate sites from one VPS to another, to manage more than one site and to synchronize easily between them. It assumes that you are running your own cloud server, have Drush on it, and have already installed a Drupal site.

Drush Aliases

Drush aliases are a simple set of configuration that allows you to reference Drupal sites from anywhere in your server's folder structure by using a shortcut of the following format @site. Before being able to use these shortcuts though, you'll need to configure the respective alias. To do this, and if you don't have one already, create a file called aliases.drushrc.php in the .drush folder that resides in your server's root folder:

nano /root/.drush/aliases.drushrc.php

Here, you have to create a php opening tag, <?php, for the file and below copy the following array declaration:

$aliases['site1'] = array(
 'root' => '/var/www/drupal_folder',
 'uri' => '88.88.88.88/drupal_folder',
);

Save the file, exit, and the alias is set. To test it out, navigate to a folder that is outside of your Drupal site and run the following command:

drush @site1 status

Now you should get the regular status information about the site you just referenced in the alias. And you can use this shortcut also with other commands.

Migrating sites

Now that you know how to reference sites, we can look at migrating (copying) a site from one folder to another using Drush. Let's say you want to move @site1 from /var/www/drupal_folder to /var/www/drupal_folder2.

First, you need to create a new alias for this future installation. For this, like always, edit the aliases.drushrc.php file:

nano /root/.drush/aliases.drushrc.php

Here, you need to create below two aliases, both with the same format. Just copy-paste the old one and make the appropriate changes:

$aliases['site2'] = array(
 'root' => '/var/www/drupal_folder2',
 'uri' => '88.88.88.88/drupal_folder2',
 );

Save the file and exit. If you run drush @site2 status, it will not work because obviously the folder not only does not contain a Drupal installation, but it doesn't even exist. So let's create it:

mkdir /var/www/drupal_folder2

In order to prepare for the new Drupal installation, you'll need to create a new database as well. So login to your MySQL through your preferred way and create a new database, making a note of the access username and password. If you are unsure how to do this, read the tutorial that shows how to deploy a Drupal site with Drush.

Now that your database is set up, you can proceed to migrate the site. To copy all the codebase from the first folder to the other, run the following command:

drush core-rsync @site1 @site2 --include-conf

Now, edit this newly copied settings.php file in the drupal_folder2 copy and change the database information to reflect the new database you just created.

nano /var/www/drupal_folder2/sites/default/settings.php

In this file, you need to make changes to the following block of code to reflect your own database information:

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'your_db',
      'username' => 'your_username',
      'password' => 'your_password',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

Save the file and exit. Now you can also migrate the database using Drush because it knows that the site in the drupal_folder2 now uses this database, even if it's currently empty. All you need to do is run the following command:

drush sql-sync @site1 @site2 --create-db

This will drop the tables in the database associated with @site2 (the one that is currently empty) due to the --create-db option and insert the ones from the database associated with @site1 - your original Drupal installation. So now you have 2 exact replicas of the same site.

You may run into the following error message (with the applicable credentials):

ERROR 1044 (42000) at line 1: Access denied for user 'your_username'@'localhost' to database 'your_db'

If this is the case, make sure that your user has the required privileges.

Log into MySQL (mysql -u root -p).

Grant the following privileges:

grant all privileges on your_db.* to your_username@localhost with grant option;
grant reload  on *.* to druser2@localhost;
flush privileges;

Synchronizing Drupal Sites

Now that you have a duplicate of your original site (@site2), you can use it for development work. If you make codebase modifications to it, you can use the core-rsync command to sync the files with the original (@site1):

drush core-rsync @site2 @site1

Obviously, you would not want to copy the settings.php file again, which prevents making database changes again. Next, to sync the database as well, run the same sql-sync command:

drush sql-sync @site2 @site1 --create-db

In most cases, it's recommended that the receiving database is emptied before the copy (using the --create-db option) to avoid conflicting configuration saved in the database that will then cause problems.

Remote sites

nano /root/.drush/aliases.drushrc.php

And let's create a new alias for a site on a remote server. Copy the following code below and replace appropriately with your information:

$aliases['site3'] = array(
   'root' => '/var/www/drupal_folder3',
   'uri' => '99.99.99.99/drupal_folder3',
   'remote-host' => '99.99.99.99'
 );

So, what does this mean? The site with the alias @site3 is located in the folder drupal_folder3 on the remote server and has that URI pointing to it on the remote server. This is to be expected. Additionally, you have to specify the remote host (which is the IP address of the remote host). Given that you have set up SSH keys, you will not be required to enter a password unless of course you have a password protecting your private SSH key itself, which I recommend if you are creating keys between two remote hosts (none being your personal computer).

And that's it. Now when you run the commands we've be talking about, you can perform the same actions remotely, as well as migrating and keeping sites synchronized. But just to test out the alias, run:

drush @site3 status

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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