About Upgrading TimesTen Classic
The TimesTen Kubernetes Operator supports the upgrade of TimesTen Classic to a new patch or patchset.
-
Auto(default): The Operator does the upgrade for you. -
Manual: You do the upgrade manually.
The .spec.ttspec.imageUpgradeStrategy datum for a TimesTenClassic object lets you choose the type of upgrade. You set a value for this datum when you initially create and deploy a TimesTenClassic object. For more information about the imageUpgradeStrategy datum, see TimesTenClassicSpecSpec.
No matter what type of upgrade you choose, what happens during the upgrade is similar. The standby is terminated first. It takes some time for the standby to come back up. During this wait period, the standby is upgraded to the new release. During this upgrade of the standby, depending on your replication configuration, there may be disruption on the active database. This may impact your applications. Next, the failover from the active to the standby occurs. The active is terminated. There is a wait period for the former active to come back up. During this wait period, the active is upgraded to the new release. The standby database is promoted to be the active and the former active becomes the standby.
Note:
If you are using AWT cache groups, the standby is normally responsible for transmitting committed transactions from TimesTen to the Oracle Database. While the standby is being upgraded, the active takes on this responsibility. This may increase the load on the active. In addition, part of the upgrade process involves copying the database from the active to the standby. This also increases the workload on the active. These increases may temporarily reduce the performance of the active database.
Ensure you perform an upgrade at the appropriate time. TimesTen recommends that you do not perform upgrades at the busiest time of a production day. Applications see shortages and perhaps reduced performance as a result of the upgrade procedure.