Upgrading from 3.16.8 to 3.18.7

nnhubbard · November 19, 2008, 8:05pm

We are looking into doing an upgrade ourselves in the next week, and I wanted to get some thoughts and comments on the process just to make sure that we are doing everything correctly.

First off, we are going to take the server down for the upgrade time, and just put up a maintenance message (and our students are all gone for Thanksgiving). So, we don’t have to worry about moving the site to another live server during the upgrade.

Basically, I will follow these steps: http://www.matrix.squiz.net/resources/upgrading/upgrade-3.16-to-3.18

We are using Debian, which I also want to upgrade, so here is my thought process:

[list=1]

Take site offline and upgrade Debian
[*]Upgrade PHP to PHP5, as well as the php5-cli and php5-pgsql modules.
[*]Follow the instructions on the link above to get the new Matrix Source Code (actually will be using the SSV file Squiz gave me), and do all the upgrade steps.
[*]Start up the server again, and we should be running 3.18.7!

Does anyone see any huge problems with this? We do have a webserver, and a database server, so I may need to upgrade Debian on the DB server as well.

Has anyone here done a similar upgrade themselves on a fairly large system?

Dan_Simmons · November 19, 2008, 9:22pm

Hi Nic,

If your system is large, I would highly recommend doing a test upgrade first (on a separate server) and test your system thoroughly prior to doing the live upgrade. Make sure you test that Paint Layouts and URLs are working correctly.

Also, if you use bulkmail, be aware that we’ve experienced some problems with sending bulkmail on 3.18.7 (fine on 3.18.6, however), so you should test that too!

Other than that, note that PHP5 now uses PDO so you’ll need that module too, and the SSV version has extra requirements over the GPL version:

http://matrix.squiz.net/resources/requirements

nnhubbard · November 19, 2008, 9:28pm

Yes, this was my intention as well. We have two older servers that I am going to use. I am just unsure about the best method to move the two live systems over to the test systems. Either way it seems there will be some downtime. Are there specific ways that Squiz does this?

kjb · November 19, 2008, 11:08pm

do you have some sort of cache / load balancer sitting in front of MSM? - if so (and you are pre-caching) there wont be much of a hit on the actual servers so you could draft in temporary boxes (the 'old' ones or even VM) do the upgrade on them -> point the cache at the temporary machines -> backup and restore to the live servers (with your upgraded PHP etc - pretty sure you have to recompile any accelerator as well[?]) and then switch back... downtime = restarting the caching servers x2. Of course this means restricting/locking editing access somehow but I always thought that would be a cool feature anyway (if you are listening guys... ;-)

HTH

K

nnhubbard · November 19, 2008, 11:14pm

No, we just use the standard matrix cache.

kjb · November 19, 2008, 11:20pm

…why not stick squid in front (can be done on the same box) for 24/48 hours or so - the currency lacks a little (but there are ways round that from within MSM) but the speed is hugely improved anyway…

cheers

K

nnhubbard · November 20, 2008, 12:20am

[quote]…why not stick squid in front (can be done on the same box) for 24/48 hours or so - the currency lacks a little (but there are ways round that from within MSM) but the speed is hugely improved anyway…

cheers

K[/quote]

I don't really want to mess with Squiz. It is not the downtime I care about, it is doing a successful upgrade.

rmacdonald · November 20, 2008, 1:03am

Yeah, don't mess with Squiz!

nnhubbard · November 20, 2008, 2:52am

:)

Honestly, I meant to say Squid. I am just so used to typing Squiz!

Justin_Cormack · November 20, 2008, 9:17am

You dont need to do the database server upgrade at the same time - both versions can run with the same database version.

As Dan says, do lots of testing. There have been a few issues with the upgrade scripts that we found because the way paint layouts are applied has changed (per asset settings as well as per URL settings). Everything should be fixed now, but its best to check.

nnhubbard · November 20, 2008, 2:51pm

[quote]You dont need to do the database server upgrade at the same time - both versions can run with the same database version.

As Dan says, do lots of testing. There have been a few issues with the upgrade scripts that we found because the way paint layouts are applied has changed (per asset settings as well as per URL settings). Everything should be fixed now, but its best to check.[/quote]

Yeah we have TONS of paint layouts on our site, so this will be of high importance to me.

One last question. Since our entire site uses only one URL, www.puc.edu, if I move the systems over to a test server, this will not be www.puc.edu, rather, just an ip address probably. Which would mean all the paint layouts would not be applied for the test environment. Now, I would not want to go reapply all of those if I don't have to for that new test URL. How would it be possible to not have to do that, but still test the paint layouts within their context of www.puc.edu?

Thanks everyone.

kjb · November 20, 2008, 4:30pm

[quote]Yeah we have TONS of paint layouts on our site, so this will be of high importance to me.

One last question. Since our entire site uses only one URL, www.puc.edu, if I move the systems over to a test server, this will not be www.puc.edu, rather, just an ip address probably. Which would mean all the paint layouts would not be applied for the test environment. Now, I would not want to go reapply all of those if I don't have to for that new test URL. How would it be possible to not have to do that, but still test the paint layouts within their context of www.puc.edu?

Thanks everyone.[/quote]

…for testing - just keep MSM listening for the www.puc.edu address and then override your DNS with a hosts setting pointing at the test box instead.

K

nnhubbard · December 8, 2008, 5:37pm

Ok, I have my test machines up and running, and I going to do my test install today.

Just wanted to make sure of one more thing, what php5 packages should be installed? I am planning on installing:

php5 php5-cli php5-pdo libapache2-mod-php5 php5-pgsql

Any other suggestions to this?

Also, just wanted to check on our DSN. Our old DSN uses:

    define('SQ_CONF_DB_DSN', 'pgsql://matrix_web@webdatabase/puc_matrix_3-16-2');
    define('SQ_CONF_DB2_DSN', 'pgsql://matrix_web@webdatabase/puc_matrix_3-16-2');
    define('SQ_CONF_DB3_DSN', 'pgsql://matrix_hipo@webdatabase/puc_matrix_3-16-2');
    define('SQ_CONF_DBCACHE_DSN', 'pgsql://matrix_web@webdatabase/puc_matrix_3-16-2');

Should the 3.18 ver. look like this?

    		'db' => array (
    				'DSN' => 'pgsql:dbname=puc_matrix_3-16-2;host=webdatabase',
    				'user' => 'matrix_web',
    				'password' => '',
    				'type' => 'pgsql',
    			   ),
    		'db2' => array (
    				'DSN' => 'pgsql:dbname=puc_matrix_3-16-2;host=webdatabase',
    				'user' => 'matrix_web',
    				'password' => '',
    				'type' => 'pgsql',
    			   ),
    		'db3' => array (
    				'DSN' => 'pgsql:dbname=puc_matrix_3-16-2;host=webdatabase',
    				'user' => 'matrix_hipo',
    				'password' => '',
    				'type' => 'pgsql',
    			   ),
    		'dbcache' => array (
    				'DSN' => 'pgsql:dbname=puc_matrix_3-16-2;host=webdatabase',
    				'user' => 'matrix_web',
    				'password' => '',
    				'type' => 'pgsql',
    			   ),

Also, for some reason a long time ago Squiz named our DB puc_matrix_3-16-2, which I really don't like. Can I safely rename is back to mysource_matrix if I change other references to it? Or should I leave it?

Thanks!

gsherwood · December 9, 2008, 11:06am

The DSNs look right and yes, you can change the DB name if you change those references.

nnhubbard · December 10, 2008, 11:56pm

Ok, I have finished the upgrade successfully, all the steps ran without problems. BUT, there is a but here. When trying to log into the admin interface, it times out, and I can't get in, which seems very strange. No logs in error.log can be found pertaining to this problem. I know that our test servers are very slow, but could this be the cause of the admin interface not loading, java? It did load before I started the install on the old 3.16.8 install.

Is there anything I can check when trying to remedy this problem? The last errors I have in the error log are talking about the Condition_User_Ip, so I don't think it has anything to do with this problem.

Update: Got the admin interface to load. Threw a bit more RAM in the machine, and it now works! Hooray, 3.18.8!

We are now getting a PHP notice: Undefined index: dbsearch, just didn't know what that was referring to.

Thanks for all the help.

Huan_Nguyen · December 11, 2008, 10:40pm

make sure you data/private/conf/db.inc file has a dbsearch index in the array

      $db_conf = array (
    		'db' => array (
    				'DSN'	  => '',
    				'user'	 => '',
    				'password' => '',
    				'type'	 => '',
    			   ),
    		'db2' => array (
    				'DSN'	  => '',
    				'user'	 => '',
    				'password' => '',
    				'type'	 => '',
    			   ),
    		'db3' => array (
    				'DSN'	  => '',
    				'user'	 => '',
    				'password' => '',
    				'type'	 => '',
    			   ),
    		'dbcache' => NULL,
    		'dbsearch' => NULL,
    		);
    
    return $db_conf;

apparently it should have been in the upgrade guide, we are fixing that now

Mark_Brydon · December 12, 2008, 2:25am

The Upgrade Guide for 3.18.2 to 3.18.3 and installation instructions (for new downloads) have been updated accordingly.
I'm sorry for any inconvenience caused by this missing information.

nnhubbard · December 16, 2008, 3:45pm

Thanks for all the help.

Our upgrade to 3.18.8 on puc.edu went very smoothly!

rhulse · December 16, 2008, 6:18pm

[quote]Thanks for all the help.

Our upgrade to 3.18.8 on puc.edu went very smoothly![/quote]

Yay!

Have you noticed any performance changes?

nnhubbard · December 16, 2008, 6:25pm

Not any that I have noticed yet. I will have to see after a day of using it. :)