Upgrade and Migration Guide : Installing Maintenance Version Upgrades for 4.2 : Overview of Maintenance Version Upgrades for 4.2
Overview of Maintenance Version Upgrades for 4.2
This section describes how to upgrade from version 4.2.x to 4.2.y.
This procedure assumes you are currently running a version 4.2 cluster in a high availability deployment configuration. In a cluster without any mirror servers, downtime is unavoidable during an upgrade installation. Additionally, if a cluster without mirrors is a non-persistent cluster, servers cannot be upgraded without losing all the data.
Starting with 4.2, you can now upgrade the versions of all servers and clients in your cluster one node at a time, without shutting down the cluster and with no downtime.
In a cluster that includes mirror servers (which are in the passive-standby state), you can avoid cluster downtime by installing upgrades using a rolling upgrade. A rolling upgrade means that one by one, you shut down a node, install the upgrade on the node, and then restart the node. Your cluster will not be affected by a rolling upgrade because when an active server instance is being upgraded, the mirror server instance will take over the operations.
Note:  
In a cluster without any mirror servers, downtime is unavoidable during an upgrade installation. Additionally, if a cluster without mirrors is a non-persistent cluster, servers cannot be upgraded without losing all the data.
When you perform a rolling upgrade, a version of one client or server can continue running with a client or server of a different version, as long as they are both of the same major/minor version.
That is, the third digit of the version may be different, but the first two digits (major/minor) must be the same. For example, 4.2.1 servers can run with 4.2.0 clients. However, rolling upgrade support is not provided for a mix of different minor versions (e.g., 4.1.0 clients with 4.2.0 servers).
Note:  
When you perform a rolling upgrade, it is expected that you upgrade the entire cluster. A partially upgraded cluster is intended to be only a temporary state. You should continue to implement a rolling upgrade until the entire cluster is running on the same version.
Copyright © 2010-2017 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback