Good day everyone,

Following from last week’s System Replication overview, today I would like to cover the operation modes in detail and explain some parameters especially useful for tuning the network traffic between sites.

The original operation mode for SAP HANA System Replication was delta_datashipping which is still available for all SAP HANA releases. As of SAP HANA SPS11 operation mode logreplay is also available as a solid feature.

The underlying technology for both operation modes is (continuous) log shipping.

With delta_datashipping, the secondary node also receives delta data from time to time (every 10 mins by default) in addition to continuous redo log shipping. In case of a failover, the redo logs just need to be replayed up to the last arrived delta data shipment. And whenever the primary and the secondary nodes are disconnected (due to any reason e.g. network, hardware or service interruption), the replication is basically out of sync and once the services are restored, system replication immediately initiates a delta shipping of the missing data (instead of a full data shipping) to get in sync again which reduces the sync time between primary and secondary hosts.

Figure 1: Transportation traffic in operation mode delta_datashipping (Photo credit: help.sap.com)

Operation mode delta_datashipping provides a smaller memory footprint on the secondary node as column store tables do not have to be loaded during replication, and this allows us to run an additional non-production system on the remote site if needed. If you are planning to use System Replication as a high availability solution, this option would not be applicable though.

With operation mode logreplay, no delta shipping is required anymore. After the system replication is initially setup with full data sync, the continuous replication between primary and secondary nodes is purely based on redo logs. The redo logs are replayed immediately after arrival which makes secondary node is a like a hot standby with reduced RTO.

Figure 2: Operation mode log_replay (Photo credit: help.sap.com)

Because there is no delta shipping required anymore, the amount of data that needs to be transferred to secondary site is reduced significantly. That means the network requirements for this configuration is based on your primary system’s transactional workload resulting reduced traffic and network bandwidth between two sites. Also, because the redo logs are applied as soon as they arrive, the RTO is even shorter than delta_datashipping.

There is also a third operation mode introduced with SAP HANA 2.0 SPS00: logreplay_readaccess which is an active/active (read enabled) configuration basically allows read-only access on column tables via SQL with a delayed view on the data compared to the primary. According to SAP Note 2426477, starting with SAP S/4HANA 1610 FPS 1, ABAP applications consuming analytical ABAP CDS views through the analytical engine (ABAP’s INA interface) can be redirected automatically to the secondary if SAP HANA system replication is operating in mode logreplay_readaccess. Note that the operation mode “logreplay_readaccess” is not supported in systems running SAP HANA XS advanced yet.

5 Must Know System Replication Parameters

There are quite a few configuration aspects in System Replication and I believe below parameters are very important and especially useful if you need to maintain the stability of the connectivity time to time:

  • datashipping_min_time_interval: This parameter defines the minimum time interval between two data shipping requests from secondary system. The default value is 600 (seconds) and you may consider tuning this parameter depending on your primary system’s transactional workload. If datashipping_logsize_threshold (see below parameter) is reached first, the data shipping request will be sent before the time interval is elapsed.
  • datashipping_logsize_threshold : Minimum amount of log shipped between two data shipping requests from secondary system. Default value is 5GB.
  • logshipping_timeout: This is the amount of time the primary node waits for the acknowledge after sending a log buffer to the secondary node, default value is 30 seconds. If the primary node does not receive the acknowledge within the time defined by this parameter, it will close the connection to the secondary site so it can continue data processing. This parameter prevents primary node from blocking transactional processing in case of network failure between two sites or service interruption on the second node. If you are using System Replication as an HA solution for production systems, you may consider reducing this parameter so in case of primary and secondary nodes are disconnected, the primary node (and your productive system) would continue transactional processing. When the connection is restored between two sites, primary node will start sending redo logs based on the latest received acknowledgment from secondary node.
  • reconnect_time_interval: If primary and secondary nodes are disconnected, this parameter defines the interval between connection attempts from the secondary node to restore the services. The default value is 30 seconds.
  • enable_log_compression and enable_data_compression: : These parameters enable the compression of log buffers / data pages before sending them to secondary node. If network bandwidth is the bottleneck in the system replication setup log/data compression can improve log shipping performance because less data is being sent over the network. However, the secondary site requires additional time and processing power for compression and decompression. If you have a fast network, this could literally result a worse performance, so consider this parameter only if your network speed is reduced. The parameter can be set on the secondary node dynamically.

Have any questions about SAP HANA System Replication? Leave a comment below.


References and further reading:

How To Perform System Replication for SAP HANA

Setting up System Replication

SAP Note 2165547 – FAQ: SAP HANA Database Backup & Recovery in an SAP HANA System Replication Landscape

SAP Note 1999880 – FAQ: SAP HANA System Replication

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

SAP HANA HA and DR Series #5: System Replication

Choosing the right HANA Database Architecture


Feel free to share.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Amit Lal

    Hi Alper, Nice detailed blog…Quick question, While configuring on SPS12 primary site is having worker and standby nodes, while failover to site B, standby node logshipping is not happening, shown as UNKOWN in system replication tab, any idea?

    (0) 
    1. Alper Somuncu Post author

      Amit, I am not sure if I understand your question correctly.

      You need to check and analyze the trace files so you can find out the reason for this problem. There is a relevant SAP note in this guide which might be helpful for you:

      2081563     secondary system’s replication mode and replication status changed to “UNKNOWN”

      Source: https://archive.sap.com/documents/docs/DOC-74578

      Alper

      (0) 
  2. Amit Lal

    You simply copy pasted from  https://www.sap.com/documents/2014/06/babb2b55-5a7c-0010-82c7-eda71af511fa.html

    No plagiarism checks…LOL

    (0) 
    1. Alper Somuncu Post author

      Hey Amit, thanks for the message. I appreciate all feedbacks.

      The link you shared is the official SAP guide on network requirements. That was one of the sources I’ve looked at with couple of others while preparing this article, and as you can see at the end of the post this source is also mentioned and recommended as further reading. I used the pictures from that guide, simply because it is much faster than drawing your own pictures and again those are also credited to SAP help pages where that document was initially placed.

      When it comes to System Replication modes, there are basically two options and their concept and differences are pretty obvious, so it would not take a genius to realize my article and that document is quite similar because they are talking about the same simple concept here.

      If you don’t mind pointing out what is wrong in my post OR what is it that you don’t like about it I would really appreciate. I believe, as an IT professional myself, our time is pretty valuable and many people (including me) like the quick guidelines and when they need to deep dive into a subject, they know where to find detailed documents. That was my purpose here, to provide a clear and focused information about the subject.

      I always have look to improve, and thanks again for your feedback.

      Alper.

      (2) 
  3. Clint Vosloo

    Hi Alper,

    Thanks so much for the blog post !

    We are running HANA 2.0 SPS 01 with asynchronous logreplay_readaccess and replication is working as expected

    On the secondary system we can run SQL queries but none of the XS features are accessible through the standard URL’s such as http://<system name>:80<instance number> or https://<system name>:43<instance number>.

    Question is: are the XS services supported on the secondary node or is it just data access ?

    Thanks so much in advance

    Clint

    (0) 

Leave a Reply