Friday 4 June 2021

How to Setup SAP HANA Multi-Target System Replication

SAP HANA System Replication is a reliable high availability and disaster recovery solution that provides continuous synchronization of a HANA database to a secondary location either in the same data center or remote site as a disaster recovery site.

More Info: SAP HANA Certification

In this article fI have tried to keep it simple on how to setup a system replication when you want to replicate single primary to multiple target which may be in same data center or at remote site.

For better understanding let us assume below.

Assumption 1

SiteA is  Current Primary

SiteB is Seconday  (which is located in same data center as of SiteA)

SiteC is Second Secondary (which is at remote location and can be used as DR Site)

Assumption 2

SiteA and SiteB are managed by cluster(there are different product available for clustering for eg:- pacemaker)

Now as per the requirement SiteC should also connect as second secondary to current Primary SiteA

Since SiteA and SiteB are in same data center, we will configure

Replication mode as

◉ Synchronous in memory (syncmem)

And Operation Mode as

◉ Log Replay

Since SiteC is in another data center as remote Site, we will configure

Replication mode as

◉ Asynchronous (async)

And Operation Mode as

◉ Log Replay

Note:- The operation mode must be identical for  multi-target replications, a mixture (e.g. logreplay  from SiteA to SiteB and logreplay from SiteA to SiteC) isn’t allowed.

So the over all Scenario is as below

SAP HANA Certification, SAP HANA Learning, SAP HANA Career, SAP HANA Prep, SAP HANA Tutorial and Materials

Assumption 3

Inter node communication is established and all network related requirements are in place considering the involvement of remote Site.

Each node is able to resolve the hostname of every other node.

Technical Steps To configure Multi-Target Hana System Replication

◉ On Primary node(SiteA) login as sidadm and enable replication                                  #hdbnsutil -sr_enable –name=primary-hostname

◉ On Secondary(SiteB and SiteC) host: login as <sid>adm and stop HANA database

◉ As root user backup existing SSFS data and key files on secondary nodes (SiteB and SiteC)#cd /usr/sap/SID/SYS/global/security/rsecssfs/#mv data/SSFS_SID.DAT data/SSFS_SID.DAT.Orig#mv key/SSFS_SID.KEY key/SSFS_SID.KEY.Orig

◉ Copy the SSFS_SID.DAT and SSFS_SID.KEY from primary node(SiteA)  to secondary node (SiteB and SiteC)

◉ On secondary Node(SiteB and SiteC) Change the ownership of the file to <SID>adm:sapsys

◉ login as <SID>adm on secondary node (both SiteB and SiteC)  and Register HANA System replication as below

On SiteB

#hdbnsutil -sr_register –remoteHost=SiteA_Hostname –renoteInstance=inst_num_of_SiteA \
–replicationMode=syncmem –operationMode=logreplay –name=SiteB

On SiteC

#hdbnsutil -sr_register –remoteHost=SiteA_Hostname –renoteInstance=inst_num_of_SiteA \
–replicationMode=async –operationMode=logreplay –name=SiteC

Login as <SID>adm and start HANA on SiteB and SiteC

Validating system replication

On Primary System (SiteA) with SIDadm user run


it should take you to location


Now run


For Example:- Your output will look like below

SAP HANA Certification, SAP HANA Learning, SAP HANA Career, SAP HANA Prep, SAP HANA Tutorial and Materials

So far the configuration looks simple and straight forward. The most challenging part is successful  testing and achieve the expected outcome.

you may see below challenges during the testing :–

1. After the take over, the other existing available secondary is not automatically connecting to New primary
2. After the take over the other existing available secondary is connecting to new primary with full data shipping, however the expectation is to have only missing logs applied while re-connecting

To avoid  these challenges you need to maintain few parameter as below once you are done with all of the above configuration.

When the primary system replicates data changes to more than one secondary system, you should use force log retention and log retention propagation to reach an optimized re-sync and avoid a full data shipping after takeover or other disconnect situations.

Configure all nodes with

[system_replication]/enable_log_retention = force_on_takeover

During takeover on a secondary system, if force_on_takeover is set, the value is changed to enable_log_retention = force automatically by HANA after the take over.

This means that Your new Primary where you just did the takeover has parameter value

[system_replication]/enable_log_retention = force 

Now, After the takover is completed and you did all the system sanity check, update the parameter to force_on_takeover from force. This will ensure that when next time you take over, your older primary should connect back to new primary with missing delta log only

Set below parameter for automatic registration of existing available secondary to new primary

global.ini/[system_replication]/register_secondaries_on_takeover paramater = true 

Suppose you take over on secondary Site B in data center 1 from primary SiteA in same data center, As a result, secondary SiteC in data center 2 will register automatically to the new primary SiteB in data center1.

After the failure on the previous primary SiteA is solved, register it to the new primary SiteB in data center 1.

If you want to re-order your systems in a complex system replication, This can be done by setting the following parameter in global.ini:

[system_replication]/propagate_log_retention = on.

Log retention propagation is used to retain the log based on the smallest savepoint log position in the whole system replication
If you want to propagate log retention in a system replication landscape between all systems, this parameter should be set on all systems in the landscape.

There can be a situation during the testing that you take over to DR site SiteC from SiteA, meaning

You take over to Site C in remote Data Center from primary SiteA, and as per the above configuration your existing availble secondary SiteB should automatically connect with Missing Delta log to new Primary SiteC. However,  SiteB  will connect with SiteC as syncmem and logreplay. In this situation you need to update the topology manually and change the replication mode from syncmem to async as we are connecting to remote sites.

You may use below command to update the replication mode

hdbnsutil -sr_changemode --mode= async

This command needs to be executed with SIDadm user and from the secondary Site for which you need to change the replication mode.

However, you may encounter such situation during the testing only. As till the time SiteB in same data center is available, you will always prefer to takover to SiteB.

No comments:

Post a Comment