SAP HANA system replication provides the possibility to copy and continuously synchronize a SAP HANA database to a secondary location in the same or another data center. Usually system replication is used to support high availability and disaster recovery.
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.
System replication is set up so that a secondary system is configured as an exact copy of the active primary system, with the same number of active hosts in each system. The number of standby hosts need not be identical. Furthermore, it requires a reliable link between the primary and secondary systems.

While registering the secondary system, you need to decide which replication mode to use. The following SAP HANA system replication modes exist:

Mode Details  Behavior when secondary system is not available
Synchronous on disk (SYNC) Primary system waits until secondary system has received data and persisted it to disk.
The primary system waits with committing the transaction until it gets a reply that the log is persisted in the secondary system. This option guarantees immediate consistency between both systems, at a cost of delaying the transaction by the time for data transmission and persisting in the secondary system.When the connection to the secondary system is lost, the primary system continues the transaction processing and writes the changes only to the local disk. No data loss occurs in this scenario as long as the secondary system is connected. Data loss can occur, when a takeover is executed while the secondary system is disconnected.
Additionally, this replication mode can run with a full sync option,  No data loss occurs in this scenario. You can set the full sync option for system replication with the parameter [system_replication]/enable_full_sync.
Primary system waits until global.ini -> [system_replication] -> logshipping_timeout is exceeded (default: 30 s) and then proceeds without replicating data.
Synchronous in-memory Primary system waits until secondary system has received data.
The primary system commits the transaction after it gets a reply that the log was received by the secondary system and stored in memory. The delay for the transaction in the primary system is smaller, because it only includes the time for transmitting the data. The disk I/O speed on the secondary system doesn’t influence the primary’s performance.When the connection to the secondary system is lost, the primary system continues the transaction processing and writes the changes only to the local disk.
This option provides better performance because it is not necessary to wait for disk I/O on the secondary system, but it is more vulnerable to data loss.
Primary system waits until global.ini -> [system_replication] -> logshipping_timeout is exceeded (default: 30 s) and then proceeds without replicating data.
Asynchronous Primary system doesn’t have to wait for secondary system (unless the asynchronous log buffer is full and waiting is configured,
This option provides better performance because it is not necessary to wait for log I/O on the secondary system. Database consistency across all services on the secondary system is guaranteed. However, it is more vulnerable to data loss. Data changes may be lost during takeover. for more info refer sap note 1999880
Primary system proceeds without replicating data.

The replication mode can be changed without going through a full data shipping from the primary system to the secondary system afterwards.
While registering the secondary system, you need to decide in which operation mode to run SAP HANA system replication.
System replication can be run in three operation modes: delta_datashipping, logreplay or logreplay_readaccess. Depending on the configured operation mode, the database sends different types of data packages to the secondary system.
The following table compares the original operation mode delta_datashipping with the operation mode logreplay available as of SAP HANA >= SPS 11:

Operation mode SAP HANA Version Description Advantages
delta_datashipping no restriction Synchronization between primary and secondary site is implemented via regular delta data shippings from primary to secondary site. Memory footprint of secondary site can be smaller as column store tables don’t have to be loaded during system replication.
As a consequence it is possible to set the global_allocation_limit (SAP Note 1999997) and run an additional non-production system on the same machine.
History tables are generally supported (for logreplay modes the restrictions described in SAP Note 2480889 apply)
logreplay >= 1.00.110 Synchronization between primary and secondary site is implemented purely based on redo logs
Column store generally has to be loaded into memory to provide reasonable delta merge speed
Delta data shipping no longer required
Reduced network traffic between primary and secondary site
Reduced network bandwidth requirements between primary and secondary site
Reduced takeover times (shorter log replay, no persistence garbage collection, no file ID mapping and disk LOB initialization, no adjustment of resource container dispositions; see SAP Note 2222217)
No propagation of logical persistence corruptions on disk level (e.g. introduced by the bug described in SAP Note 2375691)
logreplay_readaccess >= 2.00 Synchronization between primary and secondary site is implemented purely based on redo logs
Column store generally has to be loaded into memory to provide reasonable delta merge speed, See SAP Note 2391079 for restrictions.
Same advantages like “logreplay” above
Query load can be moved away from primary site

The operation mode can be checked from the following parameter:
” global.ini -> [system_replication] -> operation_mode ”
They are defined by “hdbnsutil -sr_register –operationMode= …” command.
In 3-tier environments the following details can be considered for the logreplay mode:

  • If the tertiary system is down, the logs are only saved on the secondary system, not on the primary system.
  • If the secondary system is down and you want to use the tertiary system as secondary system, usually a full sync is required, because the logs retained on primary site are meant for the secondary site and so they may not be compatible with the tertiary system.

SAP Note 2661878 provides settings that can be used to optimize the performance of logreplay on secondary system replication site. These settings are a trade-off between logreplay performance and memory utilization and secondary site, so tests are required in order to identify an optimal compromise.

Leave a Reply

Your email address will not be published. Required fields are marked *