Triggering the Upgrade, 3 questions

Triggering the Upgrade, 3 questions

by Paul Lindgreen -
Number of replies: 5

Documentation states ('..If you put your site into Maintenance mode earlier; take it out now!..') moodle should be taken out of maintenance mode before triggering the upgrade. Is this important or can I leave the site in maintenance mode to prevent other users from triggering or messing up the upgrade?

If the site is in maintenance mode I take it any user visiting the site cannot trigger the upgrade, would confusion arise if multiple users hit the site during an upgrade if its not in maintenance mode?

On a related note, is it ok to have Developer level debugging on during the upgrade?

Thanks

==environment=====

moodle 2.7, upgrading to 2.8. Windows 2008/IIS7.5, mysql


Average of ratings: -
In reply to Paul Lindgreen

Re: Triggering the Upgrade, 3 questions

by Albert Ramsbottom -

You need to take it out of maintenance mode before triggering the upgrade

But its not a good idea to upgrade a live site, really!

I would do this on a test environment and then transfer the data or put a temp page up whilst upgrading. 

BUT, you trigger the upgrade using CLI, which will be much more reliable, if upgrading to 3.0

https://docs.moodle.org/30/en/Administration_via_command_line#Upgrading

Albert

In reply to Albert Ramsbottom

Re: Triggering the Upgrade, 3 questions

by Paul Lindgreen -

Thanks for the answer to the maintenance mode question and suggestion to do it in a test environment first and using the CLI.

We have a test environment but wouldn't we have to sync everything up  while live is placed in maintenance mode before doing the upgrade? This would be time consuming transferring the live 300gb moodledata folder to the test environment along with restoring the live DB into the test environment.

We haven't been using the CLI and Git, guess we should look into it if its more reliable. Our upgrades have been nerve racking thus far.

In reply to Paul Lindgreen

Re: Triggering the Upgrade, 3 questions

by Ken Task -
Picture of Particularly helpful Moodlers

Depending upon environments ... live server -> test server and the specs of test server, one of the easiest and most reliable ways is to use rsync for all of it ... DB, code, and data directory.   Initial rync will take time, but if one runs the rsync again where what's new gets xferred and what's been removed gets removed on test server, it's fairly short time to wait.

Git and CLI is definely more reliable ... IMHO ... git dependent upon how much one might have customized site (hacked code, etc..)   The the CLI upgrade is best me thinks as it takes Apache out of the loop ... just php and your MySQL/DB server then ... even if that DB server is a dedicated box.

Have one server right now that resides on a CentOS 5 server (true standalone) which has only 2Gig memory.   Have already rsync'd all of it to new server that has same version of CentOS but more memory, faster processor, etc..   When it's current environment can't handle the load, I think I'll be able to get the site migrated in less time and more accurately.   New location already has virtual apache config for it and it's just a matter of final xfer via rsync and changing DNS.   Since I'm anticipating this migration to be called for in a reactive mode, I run the rsync scripts once a week now.   And use 'stealth mode' access to the new location to check it.    So far ... no issues on testing.

'spirit of sharing', Ken

In reply to Paul Lindgreen

Re: Triggering the Upgrade, 3 questions

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

I have run several upgrades while Maintenance mode is on and never seen an issue - I am actually surprised that is in the documentation - I have never seen that before.  Maybe something new with the later versions...

There is a new feature in Moodle which is worth turning on so that a password is required to trigger the upgrade.  I am not sure that Maintenance Mode actually stops anyone being able to trigger the upgrade...

Pro's and cons with debugging on at that level - it is probably going to print out a huge amount of stuff along the way but if you run into an issue, at least you will have that information (though I have found for the most part that if an install fails, it will tell you why regardless of debugging level.)

As for not upgrading a live site???  Yes, test it first and of course have a backup, but I think the majority of us then go ahead and upgrade live.

In reply to Emma Richardson

Re: Triggering the Upgrade, 3 questions

by Albert Ramsbottom -

Whatev's as they say

But CLI all the way with this one, CLI maintenance mode, CLI upgrade, then CLI out of maintenance mode

BUT..


Emma is right, I am only going on what the documentation says because I have also upgraded in maintenance mode as well 

wink