3.6.0 Matrix Server Upgrade Guide (5697-7085, February 2008)

Chapter 3: Rolling Upgrades 17

Rolling Upgrade Procedures

The rolling upgrade procedure does not require any matrix downtime.

Each server is removed from the matrix, upgraded, and then returned to

the matrix.

There are two procedures:

• Upgrade Matrix Server and reinstall the operating system. See page

18.

• Upgrade Matrix Server without reinstalling the operating system. See

page 20.

Rolling Upgrade Considerations

You should be aware of the following when upgrading Matrix Server to

the 3.6.0 release:

• Servers can be upgraded one-at-a-time during the rolling upgrade.

The server with the numerically highest primary IP address must be

upgraded first. Then continue to upgrade the servers in descending

order of IP address, with the server with the lowest primary IP

address being upgraded last.

• It is important to upgrade all nodes in the matrix within a short time

frame. We do not recommend running the matrix for an extended

period of time with only some of the nodes upgraded to 3.6.0. This

release introduces a new configuration data repository and a new

logging facility that do not become fully functional until all nodes are

upgraded. If the matrix is only partially upgraded, alerts raised by

nodes running 3.6 will be improperly logged by nodes running 3.4.

Also, until the entire matrix is upgraded, many services that are run

on 3.6 nodes must be run as local system administrator.

• Maintenance operations performed via MxDB for SQL Server are not

supported while the matrix includes a mix of 3.6.0 and 3.4.x servers.

Do not change the state of virtual SQL Servers until all of the nodes

have been upgraded to 3.6.0.

• During the upgrade, the PolyServe Management Console will show

the version of Matrix Server that is currently running on the server to