SAP HANA HA and DR Series #5: 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.
System Replication is a standard SAP HANA feature. In this method, all data is replicated to the secondary site and data is pre-loaded into memory on the secondary site which helps to reduce the recovery time objective (RTO) significantly. So in case of a failover, the secondary site will be able to take over without even performing a HANA DB (re)start and will work as primary DB straightaway.
Once the system replication is configured properly, each HANA internal process (nameserver, indexserver etc) connects to its counterpart on the secondary site, and all logged changes in the primary location are replicated to secondary site continuously through persisted redo logs. While system replication is running, the secondary site is on standby mode with data already pre-loaded into memory, and ready to take over. Please note that, in this scenario secondary site does not accept any requests or make any changes on DB.
Figure 1: SAP HANA System Replication Overview
Network requirements
Network requirements are usually overlooked when it comes to System Replication but it is very important to have a good network and bandwidth in place, especially for remote disaster recovery site. Because the data is continuously replicated to the secondary site, network bandwidth and latency should be sufficient to fulfil requirements. To estimate the network requirements, you need to know the size of data and log that are generated during your daily workload so you can make an informed decision.
You can use HANA_Replication_SystemReplication_Status.sql attached to SAP Note 1969700 – SQL Statement Collection for SAP HANA. On the primary system, simply choose System Information tab and right-click in the “Name” column and choose Import SQL Statements, choose SQLStatements.zip attached to that note, and you will get complete set of useful SQL statements.
Figure 2: Bandwidth script for System Replication
Running this script by default will give you default the results based on snapshot time:
Figure 3: Default bandwidth results based on Snapshot time
In the SQL statement, change the TIME_AGGREGATE_BY value so that the results are displayed per ‘DAY’; so just replace TS900 with DAY as you can see below:
Figure 4: Updating the bandwidth script
And execute the script with newly updated DAY value:
Figure 5: Bandwidth results per day
As you see above, you will have details in terms of data and log size, log percentage and bandwidths. Note that this is not an actively used system so the values would be quite different than an active HANA system.
Now, you know your SAP HANA bandwidth and can determine your network requirements especially for remote site with system replication in place.
What if I need to reduce network bandwidth?
There are two methods basically; first you can compress the data (as of SPS09) before sending and secondly use continuous logreplay feature (as of SPS11) to reduce the network bandwidth requirements.
For data and log compression, you just need to set “enable_data_compression” and “enable_log_compression” parameters true in global.ini, note the default value for these parameters is false:
Figure 6: Data compression parameters to reduce bandwidth
Continuous logreplay was introduced with SPS11 and it is another useful feature helps to reduce the bandwidth requirements. With this operation mode, the delta data shipping (which was available before) is not required anymore – only the initial full data shipping is performed and the continuous shipping of redo log continues afterwards. The amount of data that needs to be transferred to the secondary site is reduced dramatically (because no delta data shipping is required anymore). There is much less traffic on the network between the participating sites when running in operation mode logreplay.
Figure 7: Operation mode logreplay: Initial full data and redo log shipped to secondary.
System Replication is a comprehensive subject and I have decided to separate it to several articles each focused on specific areas. I am planning to cover system replication modes, operation modes, failover decision making process, key benefits and trade-offs, configuration steps, fine tuning HANA parameters for system replication and finally a summary for available options.
For a proper system replication solution, it would be better to ensure all the requirements are met, and that’s why today I started mainly with network requirements. This will take some time but hopefully I will be able to help you to make better informed decisions for your SAP HANA high availability and disaster recovery solutions.
Have any questions about SAP HANA System Replication? Leave a comment below.
References and further reading:
How To Perform System Replication for SAP HANA
Automate your SAP HANA System Replication Failover (SUSE)
SAP Note 1999880 – FAQ: SAP HANA System Replication
SAP Note 1969700 – SQL Statement Collection for SAP HANA
Network Required for SAP HANA System Replication
If you liked this post, you might like these relevant posts:
SAP HANA High Availability and Disaster Recovery Series #1
SAP HANA HA and DR Series #2: Redundancy and Fault Recovery Support
SAP HANA HA and DR Series #3: Host Auto-Failover
SAP HANA HA and DR Series #4: Storage Replication
Choosing the right HANA Database Architecture
Feel free to share.
Hi Alper,
Excellent blog & thanks for sharing this information !!
I have question on DR.
We have three production systems (2 erp system and one bw system) all these system are running separately (standalone).
We want to built DR for these 3 servers for that we decided instead of having three separate machines we want take one server and follow MDC (multi tenant database container) and create three databases and configure system replication, just wanted to confirm with you if this is ok?
Kindly give your inputs..
Thanks
Tabrayz
Hi Tabrayz, sorry for my late answer, I usually am more active on LinkedIn.
Yes, this approach is supported.
Keep in mind that if you configure system replication in MDC setup, failover cannot be performed for only one tenant database. That means you either failover all 3 databases to the second node, or none of them.
If possible, I would suggest to separate ECC systems and combine the less critical one with BW system. So all 3 databases converted to MDC, in system replication 2+2 hosts solution. If there are hardware requirements, you can also combine all three into 1 HANA host in MDC.
Regards,
Alper
Hi Alper,
Thank you so much for the reply!
As you said if we are going with MDC approach then we cannot do individual fail over, hence any other approach where we can have individual fail over and fail back?
Please keep in mind that we cannot have additional hardware for DR systems.
A part from MDC is there any other approach where we can have multiple databases.
Thanks
Tabrayz
So you only have 2 HANA hosts, and you want to have individual DR solutions for all 3 databases, correct?
If you prefer individual DR solution for each databases, MDC is not an option.
Two other options are available though, but they require sufficient hardware resources.
You can do Physical Server Partitioning, which basically 1 HANA server split into three fractions physically. So you install 3 different OS, and all databases have their own schemas.
Another (and probably more suitable) option is MCOS (Multiple Components in One System). With this approach you basically install 3 HANA instances on 1 HANA hosts (e.g. HD1, HD2 and HD3).
Both of these options are non-MDC so you can individually configure System Replication.
However, please double-check System Replication configurations and features/limitations with all your options so you can make a better informed decision.
I published an article about SAP HANA architecture a while ago, have a look: https://blogs.sap.com/2017/01/09/choosing-the-right-hana-database-architecture/
Regards,
Alper
Thanks Alper !!
As you mention I think MCOS is better option in case of individual fail over and fail back and if we have sufficient hardware (memory & cpu) then i do not see any performance issue correct me if i am wrong?
I too agree that MDC is convenient but only draw back is we cannot have individual fail over.
Just wanted to inform you that application server will be running on a separate hardware for these dr systems. Hana appliance running with multiple DB using MCOS (HD1 &HD2) and two seperate servers for application (can be two virtual machines).
Thanks
Tabrayz
If you have powerful enough hardware, no issues. I would perform it on a sandpit first though.
Application servers can run on a separate hardware, no issues with that. Everyone loves distributed systems 🙂
Good luck with your project. Keep us updated.
Regards,
Alper
Hello Alper,
Hope you are doing good! Just wanted to let you know project completed successfully !
Now new project upgrading HANA 1.0 to HANA 2.0 so wanted to discuss with you
As we know HANA 2.0 is MDC by default hence I a have question concerning multi SID installation?
In our present environment we have three standalone systems with HANA 1.0 SP12 (single dbs)and for these three standalone systems we have DR (disaster recovery) in one single appliance with multi SID installation.
Hence when we upgrade our standalone systems to HANA 2.0 these systems will automatically converted to MDC then how about the DR system as this is a single system with multi sid I understand that we have to upgrade the DR systems as well to HANA 2.0 but my question is when we upgrade DR to hana 2.0 then this will also get converted in MDC meaning one single server will have three system dbs and 3 tenant dbs so is this supported?
As you know in multi sid each instance will have separate SIDADM user hence i have to perform upgrade on three instances separately on one single server so this will turn in to 3 system dbs and 3 tenant dbs is this ok? how hana 2.0 is getting Handel in multi sid scenario?
Please shed some light on this.
Thanks
Tabrayz
Once again thank you so much for your valuable inputs..
will keep you updated about this project !!
Thanks
Tabrayz
Hi Alper ,
Thank you for this wonderful series. In the set-up you have described where the secondary is in constant syn-up with the primary, do temporary objects like temporary table data or data stored in table variables in stored procedures also replicated to the secondary site?
Hi Benedict,
Thanks for your message and sorry for my late response. I usually am more active on LinkedIn.
Anything on the persistence layer of the primary node is replicated to the secondary node.
Kind regards,
Alper
Hi all,
I have a question regarding multi-tier system replication...:
is it recommended to separate the network for system replication you need between Host A and Host B and the one you need between Host B and Host C? Or can you use the same network and share bandwidth?
Is there a best practice whitepaper from SAP talking about this?
One additional thing...:
is it recommended in a three tier replication setup to establish a replication network between Host C and Host A?
Again, something written from SAP would help...
Thanks for your help in advance,
Karsten.
Hi Alper,
Thanks for your wonderful articles. My query is how to calculate total time for up the Standby Database.
If I have 400 GB Database and 4 MBPS MPLS line then what is the time to up the Standby Database.
Please reply.