How to do System Replication for SAP HANA?
The replication of SAP HANA ships all the data to secondary system situated at a website -
When SAP HANA system replication is allowed, every server functioning on secondary system makes a connection through the primary counterpart as well as requests data snapshot. Then, all the logged changes within primary system get replicated constantly. Every continued redo log within primary system has been sent to secondary.
Transaction within primary system is not dedicated prior redo logs are simulated. In addition, SAP HANA Multitenant
Data Center Container can too run in the SAP HANA system replication configuration. The whole system is replicated1 that is System DB as well as tenant DBs. When system replication is functioning, secondary system, configured similarly to primary would be on the standby till the takeover is done.
Replication Modes-SAP HANA hosting provides various replication modes as per the customer needs.- Synchronous - The secondary system gives the acknowledgement to the primary when the data is persisted and received to the disk.
- Synchronous in-memory - The secondary system directs the acknowledgement back the moment data is received (it might result in the performance increase based on the disk speed).
- Asynchronous - According to the asynchronous replication' design, primary system do not have to wait till the time secondary sends the acknowledgement.
In addition, the SYNC (Synchronous Replication Mode) could run with enabling the "full sync". It make sure that none of the transaction could be dedicated locally with no redo log buffers' shipping to secondary site.
Operation Modes - SPS11 SAP HANA system replication could function in two operation modes -- Delta Data Shipping - Along with constant redo logo shipping, secondary system make a request to delta data shopping with the time (in every 10 minutes). During the takeover, redo log has to be replayed until last delta data shipment arrived. (It is considered as 'classical' operation mode.)
- Logreplay - Within operation mode, redo log shipping is ended post system replication was set up initially with the complete data shipping. Redo log is repeated on secondary directly post arrival making the step unnecessary during the takeover that shortens RTO via factors. In addition, the data amount that has to be transferred to secondary website is minimized drastically as no delta data shipping is needed.
Utilizing Logreplay operation mode makes the secondary website in
SAP HANA system replication as HotStandby system.
Data moved to secondary -HANA database directs the three kinds of data packages on the network to secondary side (as per configured operation mode) the moment system replication is constituted-
- Complete data shipping - The complete set of data is made as HANA snapshot over disk of primary is sent once the system replication is done.
- Delta data shipping - In this operation mode, the data increment (the data changed since last delta data shipping) transported time-to-time (in every 10 minutes) through primary data area to secondary data area.
- Redo log shipping - Each write transaction over primary makes redo log buffers, which constantly sent to secondary site.
Takeover - Takeover is basically a name given to this process of switching the active system through present primary system in the secondary system. When takeover runs, the earlier secondary system turns into new primary system.
Replication Modes in SAP HANA
There are four primary modes of system replication in SAP HANA:
1) Synchronous In-memory Mode
This is the default replication mode. In this mode, the primary node awaits a confirmation message from the secondary node when it receives the data in its in-memory. Till this time, the primary node does not conduct any other transaction.
The biggest benefit of this mode is that it offers the least delay in the transaction. This is because if the primary node does not receive any acknowledgement from the secondary node, it does not replicate data though it resumes transactions. As a result, this mode is ideal for solutions where high availability is of the essence.
2) Synchronous Mode
In this replication mode, the primary node halts transactions until an acknowledgement is received from the secondary node. The acknowledgement indicates that the data log has been accepted.
The primary advantage of this replication mode is that it maintains consistency between the primary and secondary nodes. The waiting time of the primary node for getting an acknowledgement is 30 seconds. If no confirmation is received from the secondary node in 30 seconds, the primary node resumes the transaction without completing the replication.
Loss of data can happen only when the two nodes disconnect while the replication is going on.
3) Synchronous Full Sync Mode
This replication mode ensures complete protection of data. This is because it blocks the transactions on the primary node till replication is successfully completed on the secondary node. The full sync mode is suitable for multi-tier set ups because data security is their key concern. As the mode ensures absolutely no loss of data, it is a good fit for systems using tier-2 and 3 nodes.
4. Asynchronous Mode
As the name implies, this is a mode where the primary as well as the secondary node work asynchronously. Here, the primary node does not halt transactions till a confirmation comes from the secondary node. The primary node commits a transaction written on the log file of the primary node and sends it to the secondary node. The redo log buffers are sent to the secondary node asynchronously.
This mode is the best in terms of performance since there are no transaction delays and data consistency is maintained through the replication process.
Was this answer helpful?
8
10