MID Servers are automatically upgraded, but you can also manually upgrade each MID Server
- Automatic: Allow the instance to automatically upgrade the MID Server. This
functionality is available by default. Automatic upgrade occurs:
- Every hour, when the MID Server checks with the instance to see if there is a
different version available for upgrade. You cannot modify this time period.
- When the instance is upgraded and the MID Server for that version is different
than the version currently on the MID Server.
- When the MID Server pre-upgrade test passes without an error. Any errors encountered during
this automatic test prevent the upgrade from occurring until the issues are
resolved. The pre-upgrade test is enabled by default, but can be disabled by adding
and setting a system property.
- Manual: Manually start the upgrade by clicking a related link on the MID Server
record. Use this method when you do not want to wait until the next hourly automatic
update or if your upgrade failed and you want to force an upgrade. See Upgrade the MID Server manually for instructions.
You can configure a property that specifies a different upgrade version if you do not want to
use the default MID Server version that is determined by the instance. See Set the MID Server version for more information.
The Upgrade state
The instance initiates the upgrade by sending the autoUpgrade system
command to the MID Server. Starting with MID Servers upgrading from an Istanbul version
MID Server, the MID Server Status is changed to
Upgrading while the upgrade is running. The
Upgrading state is similar to the Paused
state. This is done to avoid potential miscommunication between the new version of the
instance and the previous version of the MID Server during upgrade. For the upgrade to run, MID
servers must be in the Up state and must be validated.
While in the Upgrading state, you cannot resume or restart the MID
Server. However, you can perform the same actions that you can when the MID Server is in the
Paused state. After a successful upgrade, the queued output is sent to
the instance and the MID Server starts retrieving new commands to process. The status also
changes to Up.
When the instance sends the
system command to the MID Server, if
it is Down
, or if it has not been
validated, the command remains in the ECC Queue until the MID Server status changes to
. Then the command is processed.
Note: If you are using an
Istanbul instance but you are upgrading a pre-Istanbul MID Server to Istanbul, these
upgrade states are not available. They are available only for MID Servers that are already
Failed upgrades are handled differently based on the version you are upgrading to:
- Upgrade to another major release: (such as Istanbul to the next full release): the status
changes to Upgrade Failed.
- Upgrade from a minor version within a release (such as Helsinki patch 1 to patch 2): the
MID Server continues using the version it is currently running. It does not perform the
upgrade and the status eventually changes to Up, assuming the MID
Server was already functioning properly.
Upgrading MID Servers in the Down state
If a MID Server is in the Down state, it cannot process the upgrade
command. When the MID Server changes to Up, it immediately checks to see
if an upgrade is necessary. If it does need to upgrade, the upgrade process starts before the
MID Server processes any other commands.
Upgrade error messages
The MID Server can display the following upgrade error messages.
Table 1. Upgrade error messages
|Unable to refresh packages
||The MID Server displays this message as a generic error when the error is not handled
by a defined error message.
|Failed to query instance for MID Server buildstamp
||Instance is unavailable or there is a major version mismatch between the MID Server
and the instance.
|Not a valid package buildstamp
||InstanceInfo returned an assigned buildstamp that was not in the correct format, such
as a version mismatch.