Web development and useful information

Nathan's Blog

Upgrading to Moodle 2.3

Moodle 2.3 was released on Tuesday (release notes).
I updated my college’s Moodle from 2.2.3 to Moodle 2.3 last night. The upgrade took 21 minutes.
I encountered a few problems during the upgrade so thought I’d post these here.

In making the move to Moodle 2, we decided to create a fresh install, then import courses and resources from 1.9 to our fresh 2.2 install. Two temporary virtual servers were created for our fresh install.

Our Server Setup

Moodle code and MoodleData server

  • Windows Server 2008 Standard (SP1) (64-bit)
  • (2x) 2.4 GHz Intel Processors
  • 4 GB RAM
  • IIS7
  • PHP 5.4 (x86) (Non thread safe, PHP via FastCGI)

Database server

  • Windows Server 2008 Standard (SP1) (64-bit)
  • (2x) 2.4 GHz Intel Processors
  • 4 GB RAM
  • MySQL 5.5.23 (InnoDB table engine used)

Problem 1

Getting MOODLE_23_STABLE into our forked copy of Moodle
Having forked Moodle in April 2012 our copy did not contain the latest MOODLE_23_STABLE branch so I had to get this branch from upstream.

I used the following Git commands to do grab MOODLE_23_STABLE:

# get MOODLE_23_STABLE branch and other changes
git fetch upstream

# create a new branch that tracks MOODLE_23_STABLE from the official Moodle repository
git checkout -b MOODLE_23_STABLE upstream/MOODLE_23_STABLE

# The -u switch sets up tracking to the specified remote: our copy of moodle, 'origin'
git push -u origin MOODLE_23_STABLE

# switch to the latest stable branch
git checkout MOODLE_23_STABLE

# pull down the latest changes locally
git pull MOODLE_23_STABLE

I now had the latest stable version of Moodle on our server so could continue with the upgrade.

Following Instructions

I followed the guide to upgrading to Moodle 2.3: http://docs.moodle.org/23/en/Upgrading_to_Moodle_2.3

System Requirements
I checked the system requirements for Moodle 2.3 and saw that we met them.

Maintenance Mode
I put our Moodle 2.23 into maintenance mode so only the administrator could work on the site.
I then went into IIS7 Server Manager and stopped the server. I wanted to make sure no changes would be made to the Moodle database or MoodleData.

Disabled The Cron Scheduled Task

Backup!
I backed up our:

  • Database
  • MoodleData folder (98 GB)
  • Moodle files (2.23) (checked out conel-MOODLE_22_STABLE using Git and copied the contents)

I used MySQL Workbench to backup our Moodle database. I used the ‘Export to Dump Project Folder’ option. This saves each table into a separate file, allowing a selective restore. You can still import all tables at the same time by selecting the folder these are stored in.
I copied MoodleData and the core moodle files using Windows Explorer, renaming them moodle22_backup, moodle22_DBbackup, moodle22_MoodleData.

It took 1.5 hours to copy our 98 GB of MoodleData.

While it was copying I read the Moodle installation problems forum to get an idea of common upgrade problems I might face. http://moodle.org/mod/forum/view.php?id=28

When MoodleData had finished copying and I was confident I could restore to 2.2 if anything went wrong with the upgrade, I started the server and browsed to the admin page.

It detected the new Moodle 2.3 version and went through the requirements check – OK.
The next page listed the updates that were to be made. There was a useful button which checked for any updates to blocks and modules. It’s recommended that before upgrading, you have the latest versions of blocks and modules. I updated one block that had updates and pressed next to start the upgrade.

Time Your Upgrade
It’s a good idea to time your upgrade. I started my timer. After five minutes I experienced a server timeout error.

Problem 2

Server timeouts
My first and second attempt to upgrade Moodle failed after 5 minutes. This suggested to me that I needed to increase timeout settings on our server.
I updated PHP’s maximum execution time to be 3600 seconds (1 hour). Not knowing how long upgrades took, I thought this would be fine. I restarted the server.

Not knowing if the Moodle upgrade would continue where it left off, I refreshed Moodle and saw a message saying, “Site is being upgraded, please retry later”.
Knowing I’d restarted the server already so killed any PHP processes running during the upgrade I restored the database to its previous 2.23 state. I then retried the upgrade.

My second attempt at upgrading failed with the same 500 Internal Server Error message. I realised then that I had not changed FastCGI’s timeout settings.
In FastCGI settings I changed: Activity Timeout, Idle Timout and Request Timeout to 3600 seconds (1 hour). I restored the database to its previous 2.23 state again. I didn’t restore MoodleData. I restarted the server.

My third attempt was successful!
It took 21 minutes to upgrade.

Moodle then displayed lots of updated plugin settings. I left most as their defaults and continued. I then took Moodle out of maintenance mode and had a quick play with the new file enhancements. They’re great!

A big thanks to all the developers who contributed to this fine release!

Previous

Using Git on port 443 through a proxy

Next

Using Git with Moodle

1 Comment

  1. Also, I utilized MySQL Workbench to reinforcement our Moodle database. I utilized the 'Fare to Dump Project Folder' choice. This spares every table into a different record, permitting a particular restore. You can even now import all tables in the meantime by selecting the organizer these are put away in. Thank you so much.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by WordPress & Theme by Anders Norén