Overview of the Backup, Destroy, and Re-Create Upgrade Method
This upgrade procedure requires downtime of the cluster, which can be mitigated by temporarily switching your cluster traffic to a single transition server. For details on using a transition server, see Using a Transition Server to Mitigate Downtime While Upgrading Your Cluster. Although the use of a transition server can mitigate downtime, you will experience slower performance since a single server does not provide the same performance as a cluster.
This procedure requires you to back up the cluster database, destroy the database, install and configure the new SBRC software, and re-create your database. You should schedule a maintenance window when performing this upgrade, even if you use a transition server to mitigate a complete outage. If you are using a transition server, do not proceed with this upgrade until you have tested the operation and performance of the transition server.
This upgrade method results in the data nodes using a multi-threaded process, which provides improved performance over the single-threaded data node processes in previous SBR Carrier software releases.
The example procedures in this section assume your cluster consists of two SM nodes and two data (D) nodes as follows:
First SM node, uranus-js (10.13.20.89)
Second SM node, sbrha-3 (10.13.20.77)
First D node, sbrha-9 (10.13.20.83)
Second D node, sbrha-7 (10.13.20.81)