Technical Articles
Near Zero Downtime HANA update options for three tier HSR setup
HANA DB update of 3 tier HSR enabled system
There are 2 ways to perform 3 tier near-zero downtime HANA DB update ( replication (A->B->C) )
1.Disconnect Site C, and update it separately , and w.r.t Site A and B follow the Near-zero downtime approach for 2 tier system . Post this site c can be connected back
2.Perform 3-tier near zero downtime operation
Method 1:Disconnect Site C, and update it separately , and w.r.t Site A and B follow the Near-zero downtime approach for 2 tier system . Post this site c can be connected back
Steps:
1.Make SiteC as standalone (Execute a take over in Site C and perform a HANA DB update in Site C)
2.Perform NZDU upgrade between Site A and Site B
Steps:
a.Configure a user under SRTAKEOVER key in hdbuserstore using systemDB port in SystemDB (not tenant DB)
- Create a user with the required privileges
CREATE USER MY_REPO_IMPORT_USER PASSWORD MyRepoUserPW123;
GRANT EXECUTE ON SYS.REPOSITORY_REST TO MY_REPO_IMPORT_USER
GRANT REPO.READ ON “.REPO_PACKAGE_ROOT” TO MY_REPO_IMPORT_USER;
GRANT REPO.IMPORT TO MY_REPO_IMPORT_USER; GRANT SELECT ON _SYS_REPO.DELIVERY_UNITS TO MY_REPO_IMPORT_USER;
GRANT REPO.ACTIVATE_IMPORTED_OBJECTS ON “.REPO_PACKAGE_ROOT” TO MY_REPO_IMPORT_USER;
- As <sid>adm configure a user in the local userstore under the SRTAKEOVER key. Use a public host name to access the corresponding SQL port of the System DB (<SystemDBsqlport>). Execute this command on the primary and secondary systems
hdbuserstore SET SRTAKEOVER <publichostname>:<SystemDBsqlport> <myrepouser> <myrepouser_password>
(Above command only in systemDB, not in tenant DB)
For example, for public host name “mypublichost” and system number “00”, “MY_REPO_IMPORT_USER”, and “MyRepoUserPW123” : hdbuserstore SET SRTAKEOVER mypublichost:30013 MY_REPO_IMPORT_USER MyRepoUserPW123
- In a scale-out configuration, the command has to be executed on all hosts
b.Performing NZDU in HANA
Assumptions:
a.System replication is configured and active between two identical SAP HANA systems.
b.The primary system is the production system.
c.The secondary system will become the production system after the upgrade.
d.The prerequisite is to run both systems with the same endianness.
Steps:
-
- Upgrade the secondary system’s SAP HANA server software and all other components. From your installation directory execute as root:
./hdblcm –action=update
-
- 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.
- Stop the primary system.
- Perform a takeover on the secondary system, switch virtual IP addresses to the secondary system, and start using it productively. As <sid>adm perform a takeover:
hdbnsutil -sr_takeover
-
- If XS Advanced is being updated as well, update the XS Advanced applications.
./hdblcm –action=update
-
- 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 –hdbupd_server_nostart
-
- Register the original primary as secondary as <sid>adm.
hdbnsutil -sr_register –name=<secondary_alias> –remoteHost=<primary_host> –remoteInstance=<primary_systemnr> –replicationMode=[sync|syncmem|async]–-operationMode=[delta_datashipping| logreplay|logreplay_readaccess]
-
- Start the original primary
Method 2: 2386973 – Near Zero Downtime Upgrades for HANA Database 3-tier System Replication
Assumptions:
In these scenarios, there are three SAP HANA systems A, B and C, named SiteA, SiteB, and SiteC.
In the below example it will be assumed, that replication mode SYNC was configured between SiteA and SiteB and ASYNC between SITEB and SiteC (SiteA –sync–>SiteB –async–> SiteC).
* [A], [B], [C] means where the following step should be executed in SiteA [A], SiteB [B], or SiteC [C].
Steps:
First of all, upgrade SiteB and SiteC first, afterwards upgrade SiteA later
1.Site C: Stop, and upgrade the SAP HANA database with nostart option, no repo import:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB
./hdblcm –action=update -s <SID> –hdbupd_server_nostart
2.Site B: Stop, and upgrade the SAP HANA database with nostart option, no repo import:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB
./hdblcm –action=update -s <SID> –hdbupd_server_nostart
3.Site B: Start the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB
4.Site C: Start the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB
5.Site A: Check in M_SERVICE_REPLICATION that sync system replication is ACTIVE from SiteA to SiteB, and that async replication is ACTIVE from SiteB to SiteC
6.Site A: Stop the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB
7.Site B: Take over as the primary system, applications’ database connection should be changed accordingly:
hdbnsutil -sr_takeover
8.Site C: Change the replication mode of the new tier 2 secondary:
hdbnsutil -sr_changemode –mode=sync
9.Site B: Check in M_SERVICE_REPLICATION that sync system replication is ACTIVE from SiteB to SiteC
10.Site A: Upgrade the SAP HANA database with nostart option, no repo import:
./hdblcm –action=update -s <SID> –hdbupd_server_nostart
Now, SiteA is stopped, and SiteB is the primary system, and SiteC is the secondary system with sync replication mode.To restore the original multitier setup (SiteA –sync–> SiteB –async–> SiteC), SiteA should be added as the secondary site instead of SiteC, then SiteA should take over from SiteB, finally SiteC is added as the tertiary site (tier-3).
11.Site C: Stop the SAP HANA database
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB
12.Site B: Unregister SiteC from SiteB:
hdbnsutil -sr_unregister –name=siteC
13.Site A: Register as secondary:
hdbnsutil -sr_register –name=siteA –remoteHost=<hostname_of_B> –remoteInstance=<instance_number> –replicationMode=sync
14.Site A: Start the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB
15.Site B: Check in M_SERVICE_REPLICATION that sync system replication is ACTIVE from SiteB to SiteA.
16.Site B: Stop the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StopSystem HDB
17.Site A: SiteA takes over as the primary system, so applications’ database connection should be changed accordingly:
hdbnsutil -sr_takeover
18.Site B: Register SiteB as the tier 2 secondary of SiteA:
hdbnsutil -sr_register –name=siteB –remoteHost=<hostname_of_A> –remoteInstance=<instance_number> –replicationMode=sync
19:Site B: Start the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB
20:Site A: Check in M_SERVICE_REPLICATION that sync replication is ACTIVE from SiteA to SiteB.
21:Site B Enable SiteB as a replication source system:
hdbnsutil -sr_enable
22:Site C: Register SiteC as a tier 3 secondary in the multitier system replication scenario:
hdbnsutil -sr_register –name=siteC –remoteHost=<hostname_of_B> –remoteInstance=<instance_number> –replicationMode=async
23:Site C: Start the SAP HANA database:
/usr/sap/hostctrl/exe/sapcontrol -nr <instance_number> -function StartSystem HDB
Further options to reduce downtime : Execute the downtime in 2 phases:
1.hdblcm with –prepare_update
2.hdblcm like nomal so that this directly enters the downtime
Thanks for reading!
Like and leave a comment if it was useful!
Follow for more such posts! 🙂
How about HANA Client upgrade .