SAP HANA HA and DR Series #6 System Replication Op...

alper_somuncu · ‎02-28-2017

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.