6

We have a couple of updates that we'd like to run by way of a module's upgrade script. One of them takes about 5 minutes to complete.

The problem here that we are not sure about is that the site is very active.

So when we push the upgrade script to production, how will it behave?

Will the upgrade script continually be run multiple times when people are hitting the site until one instance of it is finally complete?

Is Magento smart enough to only run one instance of it (even if it is not completed yet and other people are hitting the site)?

We are on Magento EE 1.9.

  • 1
    My experience is, yes, it will. But I can't imagine this is not checked before it is run. – Fabian Blechschmidt Apr 17 '13 at 15:58
  • 1
    I can also confirm that the install scripts will run multiple times if you let the customers access the website. It had happened to me before. My suggestion is to put the website offline (except for you) when you have to run large upgrade scripts, run them and then put the website online again. – Marius Apr 17 '13 at 16:36
  • 1
    So I'm getting confirmations that the scripts can be run multiple times. I wonder why Magento allowed for this, because I can think of no instance ever where anyone would want an install/upgrade script to be run more than once. I may have to just create a standalone script then and run it on production via command line. – Prattski Apr 17 '13 at 18:51
8

In theory, yes. I have seen upgrade scripts run multiple times - which is why any upgrade script I create that loads CMS, EAV or other Attribute information typically is coded to safeguard against multiple insertion.

Best Practice:

Using SSH, run the following from your Magento document root:

touch maintenance.flag

This will create a file called 'maintenance.flag' in your Magento root that will effectively pull your store offline during this upgrade. 5 minutes of downtime should be relatively safe if you run in your off-peak or overnight hours.

Upgrade your Magento Store by running an update/pull from your source control checkout or via your preferred method of deployment. To execute your upgrade you can issue:

php index.php - again from the document root. This will kick off your upgrade.

You can allow yourself access to the CMS portion (if you rather not run the upgrade script yourself via SSH) by implementing an index.php workaround (read: hack) that allows specific IP addresses access by skipping the check of the maintenance.flag file:

$ip = $_SERVER['REMOTE_ADDR'];

$allowed = array('1.1.1.1','2.2.2.2'); // these are the IP's allowed

And replace this line:

if (file_exists($maintenanceFile)) {

with this line:

if (file_exists($maintenanceFile) && !in_array($ip, $allowed)) { 

Source: http://inchoo.net/ecommerce/magento/maintenance-mode-in-magento/

In short, recovery to clean up multiple executions of the upgrade will potentially result in longer downtime than if you had just taken the store down to begin with. Plan your maintenance and practice it in your staging environment many times before executing your upgrade.

  • 2
    Definitely not a good idea for a production site that has a lot of traffic.. – Prattski Apr 17 '13 at 18:41
  • In what way do you mean? – philwinkle Apr 17 '13 at 19:07
  • 1
    Doing this would take the site down for hundreds of people. I realize that sometimes you just may need to do this, but the people in charge wouldn't consider this to be an option at all.. I may just need to make a standalone temporary php file and run it from the command line to make sure it only runs once. – Prattski Apr 18 '13 at 14:48
  • 2
    I manage very large ecommerce stores for global publishing and fashion brands - we take the sites down for maintenance routinely. Again, this is for major upgrades (like you mention) and is in offpeak, overnight, hours. You management needs to understand that sometimes you need to close to doors to the store to do a 'floor move' in retail - then you must do the same in online sales as well. Best of luck to you - hopefully your upgrade is smooth and doesn't result in downtime anyhow. I've seen many upgrades go awry with SQLSTATE 'duplicate key' or 'foreign key' errors, causing severe downtime – philwinkle Apr 18 '13 at 15:10
  • If you get a "Status: 302 Moved Temporarily" when using php index.php, the command wget -qO /dev/null https://yoursite.com or a curl equivalent could help you. – Simon Oct 25 '13 at 11:33

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.