BigMemory 4.4.0 | Upgrade and Migration Guide | Installing Maintenance Version Upgrades for 4.2 | Installing Maintenance Version Upgrades for 4.2
 
Installing Maintenance Version Upgrades for 4.2
Use the following procedure to upgrade BigMemory Max from 4.2.x to 4.2.y.
Note:
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.
Step 1: Download the Kit
Download the BigMemory kit and verify that you have the correct license keys for the version you are installing.
Step 2: Upgrade All Terracotta Server Arrays (TSAs)
You must upgrade all TSAs in all regions before proceeding to Step 3, as follows.
1. For each mirror server instance in the cluster, do the following:
a. Shut down the mirror server using the stop-tc-server script.
b. Remove the old version of BigMemory Max from the installation directory of the mirror server.
c. Optionally delete the objectdb data that is saved in the server's data directory under /dirty-objectdb-backup/dirty-objectdb-<timestamp>. Alternatively, you can restore from the old dirty objectdb's at a later time.
d. Unzip the upgrade file in the mirror Terracotta server's installation (root) directory.
On a UNIX/Linux machine, use the tar command. For example:
tar zxf terracotta-4.2.1.tar.gz
On a Microsoft Windows machine, double-click the zip file.
e. Startup the mirror server using the start-tc-server script and wait for the synchronization to complete.
f. Confirm that the mirror server has synced with the active server. You can use the Terracotta Monitoring Console to monitor server status.
g. Confirm that the upgrade was successful by running the version check shell script. This script is available in<kit>/server/bin/version.sh (or version.bat for Windows) and prints the current kit's version in standard output. For example, this command:
$ ./version.sh
Might produce this output:
Terracotta Enterprise 4.3.0-SNAPSHOT
2. For each active server instance in the cluster, do the following:
a. Shut down the active server using the stop-tc-server script.
The cluster fails over to the mirror server, which now becomes the active server.
b. Install the upgrade on the shut-down server, the same way you installed it on the mirror server.
c. Startup the server using the start-tc-server script. The formerly active server now becomes the mirror server.
d. Optionally perform a failback to make the original active server (which is now a mirror) become the active server again. Alternatively, you can just leave it the way it is (i.e., the original active is now a mirror, and the original mirror is now an active.
To perform a failback, stop the currently active server (i.e., the original mirror server). This will cause the original active server to become the active server again. Then restart the original mirror server, which will act as a mirror server again. Lastly, confirm that the original mirror server has synced with the newly active server. You can use the Terracotta Monitoring Console to monitor server status.
3. For each client in the cluster, do the following:
a. Shut down the client. A Terracotta client will shut down when you shut down your application.
b. Upgrade the software on the client.
c. Startup the client.
To check the current versions of your cluster's nodes, the Terracotta Management Console (TMC) provides a Check Version button. For details, see the Terracotta Management Console User's Guide.
Step 3: Stop All Orchestrators
Perform this step if your cluster includes the BigMemory WAN Replication service. Stop all Orchestrators by running the stop-wan.sh or stop-wan.bat script from the kit. For example:
<kit>/server/bin/stop-wan.sh -f path/to/wan.xml
Note:
If your cluster contains standby Orchestrators that are configured to reconnect the replica caches if they become disconnected from their master caches (i.e., if the Orchestrator's replicaDisconnectBehavior parameter is set to reconnectResync ), then we recommend stopping the standby Orchestrators first, and then stopping the master Orchestrators.
Step 4: Upgrade All Orchestrators to the Same Version
Perform this step if your cluster includes the BigMemory WAN Replication service. Install the new Orchestrator version from the latest BigMemory Max kit onto your Orchestrator machines. All Orchestrators must run the same version.
Step 5: Restart All Orchestrators
Perform this step if your cluster includes the BigMemory WAN Replication service. Restart all Orchestrators with the new version by running the start-wan.sh or start-wan.bat script from the kit. For example:
<kit>/server/bin/start-wan.sh -f path/to/wan.xml
The Master region will become immediately available, and then it will resynchronize all Replica regions.
Note: The resynchronization process of existing WAN-enabled caches will depend on the value of the replicaDisconnectBehavior configuration parameter. For more information, see "Orchestrator Configuration Parameters in the BigMemory WAN Replication User Guide.