Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

MID Server upgrade

Log in to subscribe to topics and get notified when content changes.

MID Server upgrade

MID Servers are automatically upgraded, but you can also manually upgrade each MID Server separately or "pin" the MID Server to a specific version to disable auto-upgrades.

Upgrade methods

  • 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.

Pinning a MID Server to a specific version

You can specify a different upgrade version if you do not want to use the default MID Server version that is determined by the instance. This is referred to as pinning and can be applied to all MID Servers in your environment or to specific MID Servers. See MID Server version selection 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 autoUpgrade system command to the MID Server, if it is Down or Paused, or if it has not been validated, the command remains in the ECC Queue until the MID Server status changes to Up. 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 on Istanbul.

Failed upgrades

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
Message Description
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.