You can use SAP HANA system replication to upgrade your SAP HANA systems, as the secondary system can run with a higher software version than the primary system.
Near Zero Downtime Upgrade
SAP HANA offers zero downtime maintenance, together with SAP HANA system replication. You can use system replication to upgrade your SAP HANA systems because the secondary system can run with a higher software version than the primary system.
As a prerequisite, system replication must be configured and active between two identical SAP HANA systems.
If system replication is active, you can first upgrade the secondary system to a new revision so that it can take over the role of the primary system. The takeover only requires a few minutes and the committed transactions or data are not lost. You can then perform an upgrade on the primary system, which is now in the role of secondary.
The secondary system can be initially installed with the new software version, or upgraded to the new software version when replication is already configured. After you upgrade the secondary, you must replicate all data to the secondary system, which already has the new software version. When the secondary system is ACTIVE (all services have synced), you can execute a takeover on the secondary system. This step makes the secondary system productive with the new software version.
In an Active/Active (read enabled) system replication setup, the version of the primary and the secondary systems must be identical. For the near zero downtime upgrade to work, the operation mode on the secondary system is automatically set to logreplay. Like this, the two systems can get back in sync before the takeover step. To reestablish the Active/Active (read enabled) landscape at the end, the logreplay_readaccess operation mode must be explicitly specified during the former registration of the primary system as a new secondary system.
Prerequisites
You configured a user in the local userstore under the SRTAKEOVER key.
Therefore, create a <myrepouser> user with the necessary privileges to import the repository content at takeover time on the primary and secondary systems.
Set the user store entry under the SRTAKEOVER key using the following command:
12hdbuserstore SET SRTAKEOVER <public hostname>:<sqlport>
<myrepouser> <myrepousers_password>System replication is configured and active between two identical SAP HANA systems:
The primary system is the production system.
The secondary system will become the production system after the upgrade.
The prerequisite is to run both systems with the same endianness.
The process, which is described in detail in the SAP HANA Administration Guide, looks like the following:
Upgrade the secondary system:
./hdblcm --action=update
Verify that system replication is active and that all services are in sync.
Stop the primary system.
Perform a takeover on the secondary system, including switching virtual IP addresses to the secondary system, and start using it productively:
hdbnsutil -sr_takeover
Upgrade the previous primary system without starting the system. This is necessary because otherwise the primary has to be stopped again before it can be registered as the secondary.
./ hdblcm --action=update --hdbupd_server_nostart
Register the previous primary system as the secondary system:
./hdbnsutil –sr_register …
Start the previous primary system as the secondary system.
Zero Downtime Maintenance Featured by SAP NetWeaver ABAP Stack
To achieve a real zero downtime upgrade from the application server perspective, see SAP Note: 1913302 — Connectivity suspend of Appserver during takeover.
Based on the connectivity suspend feature of the SAP NetWeaver ABAP stack, DBSL of the database interface decouples transaction management between ABAP and the SAP HANA database. This keeps the transaction on the ABAP layer alive and allows the change of components (software versions) on the layers below the secondary (shadow) SAP HANA instance.
Hardware Exchange
Additionally, as described in SAP Note: 1984882 — Using HANA system replication for Hardware Exchange with Minimum Downtime, hardware can be exchanged with minimal downtime using SAP HANA system replication.