SAP HANA system replication provides the possibility to copy and continuously synchronize an 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.
───────────────▄▄───▐█
HANA High Availability Overview
HANA Replication Modes –
SAP HANA System Replication is implemented between two different SAP HANA systems with the same number of active nodes. After system replication is set up between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:
If the primary SAP HANA system fails, the system administrator must perform a manual takeover. Takeover can be performed using SAP HANA Studio or the command line.
HANA Operations Modes –
Key pointers while planning HSR scenarios –
Distance between data centers
System replication offers synchronous and asynchronous replication modes to
accommodate network latency.
If the distance between your sites is less than 100 km you can use synchronous
replication mode: SYNC or SYNCMEM.
For all data centers that are more than 100 km apart, the asynchronous replication
mode ASYNC is recommended.
Note: Depending on latency, data volume, the volume of changed data records, this
could lead to loss of changes because of missing redo logs. Please also
consider monitoring requirements for asynchronous mode.
License Validity
The primary system automatically replicates relevant license information to the
secondary. In the currently active/passive system replication implementation –
where no SQL is possible on the secondary system – no additional license needs to
be installed, since the primary and secondary have the same SID and the
secondary cannot be accessed by applications.
Further information on licensing in SAP HANA system replication can be found in
SAP note 2211663.
Resync optimization
Whenever the primary and the secondary sites are disconnected (e. g. due to
network problems, a temporarily stopped primary or secondary, or after a
takeover and prior to a failback where the former primary is registered as new
secondary), the replication is out of sync. To get in sync again after reconnecting the
SAP HANA system replication tries to achieve this by initiating a delta shipping of
the missing data (instead of a full data shipping). For the “delta_datashipping” and “log replay” operation modes (introduced with SPS11) two different attempts are in place to achieve this: Data Retention and Log Retention
New blockbusters in HANA 2.0 SPS 03 and 04 in terms of HA&DR
New in SAP HANA 2.0 SPS 04, SAP HANA system replication’s multi-target replication ability supports read access on the secondary tier with the SAP HANA, active/active read-enabled option.
◈ Global Reporting with SAP HANA, active/active read-enabled option
◈ Follow the Sun Architecture
Just like the scenario for global reporting, in the “Follow the Sun” architecture, implicit connections (hint-based routing) route to one SAP HANA instance while all SAP HANA instances in the secondary tier can support explicit connections. More than likely and for performance reasons, the SAP HANA instance that will support hint-based statement routing would be co-located in the same or near-by data center for high availability.These features are applicable to public clouds. SAP HANA system replication, key component here, is not bound to zones or regions. SAP HANA system replication has different replication modes, SYNC and ASYNC, and these can be switched to support the distanced covered. While not a pre-configured solution, customers can create this architecture.
“TELL ME AND I FORGET. TEACH ME AND I REMEMBER. INVOLVE ME AND I LEARN.” –BENJAMIN FRANKLIN
No comments:
Post a Comment