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
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
#cdpy
it should take you to location
/usr/sap/<SID>/HDBXX/exe/python_support
Now run
#python systemReplicationStatus.py
For Example:- Your output will look like below
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