Is there any special handling needed to update multiple Drupal installations with drush? (I.e., multiple installations using the same database.) We are working on automating several update processes for our Amazon EC2 instances.

Comments

greg.1.anderson’s picture

Status: Active » Fixed

I am pretty sure I have answered this a couple of times, but I can't find the issue or issues. :p This time I will update the FAQ as well!

First off, multisite is not recommended if you need it [*], primarily because when you use multisites, your upgrade process is tied together for all sites. This is because multisite shares code for Drupal core, and usually contrib modules as well (if the recommended sites/all/modules location is used to store global contrib modules). If you change the shared code by updating one Drupal instance in a multisite, you will affect all instances at the same time. It is therefore important to update multisites carefully.

1. Start by backing up all of the sites in your multisite. Then, copy your live site + database to a working site and run pm-updatecode on it. I do this step automatically on a periodic task run from cron, so I have update sites waiting for me when they become available.

2. Test! Test! Test! Any time you change code, there is the potential that recent changes might break some aspect of your site, so be sure to test every site in the multisite group very thoroughly.

3. If your sites were independent of each other, you could bring them live independently, when testing for each site was completed. With a multisite configuration, however, you cannot update one site without updating all sites at once. Do the following substeps:

a. Put all sites into maintenance mode

b. Push the updated code from your test site to the live site. You can use drush rsync, or perhaps you may store your code in a repository, in which case you can deploy by committing on the test site and updating on the live site. If you want a robust deployment mechanism with rollback capability, see the drush deploy extension.

c. Run updatedb on each site

d. Done! Bring all sites out of mantenance mode.

If you do each step carefully, it should go well. Minor updates usually come off without a hitch, but never skimp on the testing step!

---------------------------------------------------------------------------

[*] Why would you need multisite? Usually not because of disk space; disk space is cheap. The main reason for really needing multisite is if you are employing some sort of code compilation scheme, in which case shared code means less compilation and more cache sharing. Only you can decide if the benefits of multisite outweigh the inconveniences, though; choose wisely.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

thatoneguy’s picture

This is great info for multisite, but that's not what I meant. I meant multiple installations of Drupal for the same site (hence multiple servers, not sites), as in the case of load balancing. My concern would be running drush up on multiple servers using the same database. Would that cause problems updating the database? Should drush be avoided in that instance?

greg.1.anderson’s picture

You'll need to take all instances offline first; then,the process is basically as described in #1. The main difference is that in step 3c, just run updatedb once on your shared database, and then make sure that you copy the code updated in step 1 to every instance.