A rolling software upgrade provides continuous service while a new software release gets applied to the system. In short, each system is updated with the new software release independently, while the other system acts as primary during that period, removing the need for application downtime during the software upgrade.
This rolling upgrade sequence assumes that there is only a secondary instance, which is down during the upgrade. Thus, if the primary goes down during the upgrade, the application will be unavailable. Assuming that Site A is the primary before the upgrade, here are the steps to perform a rolling upgrade:
Site A continues to operate normally, (i.e., to the primary a secondary upgrade looks like a secondary failure).
On Site B:
Shut down the Source and Receiver Servers and the application. Run down the database and make a backup copy.
Upgrade the software.
If there is no change to the database layout or schema, bring the secondary back up and proceed with the planned failover (below).
Note the largest journal sequence number in any replicated database region.
Upgrade the database.
Set the journal sequence number of any replicated region to the largest journal sequence number noted above.
If there was no change to the database schema, bring the secondary back up and proceed with the planned failover (below).
If there was a change to the database schema, bring up the secondary with the new-to-old filter on the Source Server, and the old-to-new filter on the Receiver Server.
At this point, dual-site operation is restored with Site B running the new software and Site A running the old software. It may be appropriate to operate in this mode for some time to verify correct operation.
After which you can execute the following to complete the upgrade: Perform a controlled switchpver between systems. Make Site A the secondary and Site B the primary for the remainder of the upgrade.
On Site A:
Once you are satisfied with the operation of the new software on Site B, shut down the Source and Receiver Servers and the application. Run down the database and take a backup copy.
Upgrade the software.
If there is no change to the database layout or schema, bring the secondary back up. Dual-site operation is now restored, and the upgrade is complete.
Note the largest journal sequence number in any replicated database region.
Upgrade the database.
Set the journal sequence number of any replicated region to the largest journal sequence number noted above.
If there was no change to the database schema, bring the secondary back up. Dual-site operation is now restored, and the upgrade is complete.
If there was a change to the database schema, turn off the filters on Site B. Then bring up the secondary on Site A. Dual-site operation is now restored. This filter can be turned off on Site B, or by the Receiver Server on Site A when it comes up, using the -stopsourcefilter command.
While a typical upgrade may take hours, significant upgrades may take even longer. During a site upgrade, only the one primary system is available. If this is an unacceptable risk to application availability, a tertiary instance can be used so that a primary and a secondary are always available. Please consult Fidelity Information Services to further discuss this procedure.
Filters between the primary and secondary systems are required to perform rolling upgrades that involve database schema changes. The filters manipulate the data under the different schemas when the software revision levels on the systems differ.
GT.M provides the ability to invoke a filter; however, the application developer must write the filters specifically as part of each application release upgrade when schema changes are involved.
Filters should reside on the upgraded system and they should use logical database updates to update the schema before applying the updates to the database. The filters should be capable of invoking the replication Source Server (new schema to old) or the database replication Receiver Server (old schema to new), depending on the system's status as either primary or secondary.