SAP HANA 2.0 SPS 01 What’s New: High Availability ...
Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
In the upcoming weeks, we will be posting new videos to the SAP HANA Academy to show new features and functionality introduced with SAP HANA 2.0 Support Package Stack (SPS) 01.
However, as the two new high availability features for the SPS 01 release do not bring a lot of material to the table, I will take the opportunity to discuss the new operation mode in more detail. For the two new HA features, a new system parameter and a new system replication API hook, see below.
Technically, logreplay_readaccess is very similar to the logreplay operation mode as both use continuous log shipping and redo log replay on the secondary system. In other words, if you have implemented system replication using either the command line utility hdbnsutil, the SAP HANA studio, or the new SAP HANA cockpit, configuring for logreplay_readaccess is no different.There is no new skillset required.
The big difference, however, is that logreplay_readaccess allows for active client connections.
Big deal?
Yes.
Previously, SAP HANA system replication required two identical systems to be up and running with only one system actively used. Double the $$ for hardware and licenses (SUSE Linux Enterprise Server & SAP HANA). Pay 2 get 1.
In return, as part of the deal, you get no data loss and near-zero downtime for both planned and unplanned events, for both regular maintenance and for unexpected incidents to full-blown disasters. The tough questions to answer were: how much is your data worth? Can you afford to loose some of it? How long can you be offline in times of trouble?
The good news is that with the new logreplay_readaccess operation mode, also known as active/active (read-enabled), the stage for these questions has changed. Of course, the investment is still there but this time the return is much bigger (ROI). With a read-enabled secondary site, you can offload a lot of the heavy-duty, number-crunching, analytical OLAP-type queries from the primary production site. As a result, performance is improved on both sides. The primary site can handle more transactions (throughput) and the secondary site can return faster results (response times). Not only is your system highly available and setup for disaster recovery (HA/DR), but also can it deliver increased performance.
As a reminder, system replication occurs in real-time. Transactions only commit on tier 1 if tier 2 has at least acknowledged the reception of the log buffer (replication mode = synchronous in-memory) or has persisted the buffer to the redo log on disk/storage (synchronous). So, whether you query the primary site or the secondary, you get the same result. It is the same system. The operation mode logreplay_readaccess is not supported in replication mode asynchronous (nor would that be sensible).
The small print? It does not happen automagically. There is no mechanism, at least not yet, that detects a long-running, resource-hungry, read-only OLAP query to dispatch it to the secondary site. You need to either establish a direct connection to the secondary database (supported by all client APIs: ODBC, JDBC, etc.) or include a HINT in the SELECT statement to point to the secondary system.
SELECT C1, C2 FROM T1 WHERE C3 = '<constant value>'
WITH HINT(RESULT_LAG('hana_sr'))
When system replication is enabled for the first time, initialisation may take a while. Basically, the time it takes to copy the production database over the network to the secondary site. Of course, there are ways to speed up this process by restoring a system snapshot or backup to the secondary site but you may still have a considerable amount of data that needs to be copied.
To decrease the time required for this phase, SAP HANA 2.0 SPS 01 introduces the new system replication system parameter: datashipping_parallel_channels.
With this parameter you can define the number of network channels to be used for datashipping, both full and delta. With more channels available, more data can be transferred faster over the network. This assumes that there is enough data to be pushed in the first place (think GB's), that the primary server can deliver the data fast enough, and that the network still have enough bandwidth to accommodate more data transfers.
New System Replication HA/DR Provider
To enable the automation of additional tasks during the host auto-failover and system replication takeover process, SAP HANA system replication includes a Python-based API for the nameserver process. For example, to first stop the development system on the secondary site just before takeover. We refer to these as "hooks" or, more elegantly, HA/DR providers.
New in SAP HANA 2.0 SPS 01 is the srServiceStateChanged() provider. This hook enables you to monitor state changes of the SAP HANA service.
There is a sample HADR provider Python script file included with in path /usr/sap/<SID>/HDB##/exe/python_support/hdb_ha_dr/HADRDummy.py
# Access to parameters dictionary
hostname = parameters['hostname']
service = parameters['service_name']
port = parameters['service_port']
status = parameters['service_status']
timestamp = parameters['timestamp']
The SAP HANA Academy provides free online video tutorials for the developers, consultants, partners and customers of SAP HANA.
Topics range from practical how-to instructions on administration, data loading and modeling, and integration with other SAP solutions, to more conceptual projects to help build out new solutions using mobile applications or predictive analysis.