## 8.8.2  Use SAP HANA System Replication for Near Zero Downtime Upgrades
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.
## Prerequisites
You configured a user in the local userstore under the SRTAKEOVER key. For more information, see Configure a User Under the SRTAKEOVER Key .
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.
## Context
With system replication active, you can first upgrade the secondary system to a new revision and have it take over in the role of primary system. The takeover is carried out in only a few minutes and committed transactions or data are not lost. You can then do an upgrade on the primary system, which is now in the role of secondary.
##  Note
It is possible to reduce the time required to perform an update. For more information, see Prepare an Update for Flexible System Downtime .
The secondary system can be initially installed with the new software version or upgraded to the new software version when the replication has already been configured. After the secondary has been upgraded, all data has to be replicated to the secondary system (already having the new software version). When the secondary system is ACTIVE (all services have synced), a takeover has to be executed on the secondary system. This step makes the secondary system the production system running with the new software version.
##  Note
If you are upgrading from SAP HANA 1.0 to SAP HANA 2.0, copy the system PKI SSFS key and the data file from the current primary system to the new to-be secondary system:
/usr/sap/&lt;SID&gt;/SYS/global/xsa/security/ssfs/data/SSFS\_&lt;SID&gt;.DAT /usr/sap/&lt;SID&gt;/SYS/global/xsa/security/ssfs/key/SSFS\_&lt;SID&gt;.KEY
For more information, see SAP Note 2369981: Required configuration steps for authentication with HANA System Replication .
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 establish again 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.
For more information about near zero downtime upgrades when using a multitarget system replication setup, see Use Multitarget System Replication for Near Zero Downtime Upgrades .
## Procedure
1. Upgrade the secondary system's SAP HANA server software and all other components.
From your installation directory execute as root:
```
./hdblcm --action=update
```
2. Verify that system replication is active and that all services are in sync. You can check that the column REPLICATION\_STATUS in M\_SERVICE\_REPLICATION has the value ACTIVE for all services.
3. Stop the primary system.
4. Perform a takeover on the secondary system, switch virtual IP addresses to the secondary system, and start using it productively.
As &lt;sid&gt;adm perform a takeover:
```
hdbnsutil -sr_takeover
```
5. If XS Advanced is being updated as well, update the XS Advanced applications.
6. Upgrade the original primary from the installation directory as root user using the --hdbupd\_server\_nostart option together with all other components. This is necessary because otherwise the primary has to be stopped again before it can be registered as the secondary.
```
./hdblcm --action=update
```
```
./hdblcm --action=update --hdbupd_server_nostart
```
##  Note
For a fast synchronization of the sites - after registering again the original primary system - perform this failback within the time given by the datashipping\_snapshot\_max\_retention\_time parameter (default 300 minutes). Otherwise, a full data shipping will be done. Furthermore, the optimized resync depends on the availability of the last snapshot. For more information about near zero downtime upgrades in multitier system replication, see SAP Note 2386973 .
7. Register the original primary as secondary as &lt;sid&gt;adm .
8. Start the original primary.
```
hdbnsutil -sr_register --name=<secondary_alias> --remoteHost=<primary_host> --remoteInstance=<primary_systemnr> --replicationMode=[sync|syncmem|async]--operationMode=[delta_datashipping| logreplay|logreplay_readaccess]
```
## Related Information
```
Configure a User Under the SRTAKEOVER Key [page 201] Prepare an Update for Flexible System Downtime Updating the SAP HANA System Perform a Near-Zero Downtime Update Use Multitarget System Replication for Near Zero Downtime Upgrades [page 203] Deploy a Multi-Target Application with Zero-Downtime Maintenance SAP Note 2369981 SAP Note 1984882 SAP Note 2386973 SAP Note 2494079 SAP Note 2407186 SAP Note 2300936
```