SAP HANA 2.0 SPS 01 What’s New: High Availability – by the SAP HANA Academy
Introduction
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.
The topic of this blog is high availability.
For the previous version of this blog, see SAP HANA 2.0 SPS 00 What’s New: High Availability – by the SAP HANA Academy
For the full SAP HANA 2.0 SPS 01 blog list, see: What’s New with SAP HANA 2.0 SPS 01 – by the SAP HANA Academy
Tutorial Video
What’s New?
New System Replication Operation Mode: Active/active (read-enabled)
Active/active (read-enabled) system replication (logreplay_readaccess operation mode) was introduced with SAP HANA 2.0 SPS 00 and I already discussed the feature in my blog SAP HANA 2.0 SPS 00 What’s New: High Availability – by the SAP HANA Academy.
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'))
See Connecting Using Active/Active (Read Enabled) and Hint-Based Statement Routing for Active/Active (Read Enabled).
New System Replication System Parameter
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
def srServiceStateChanged(self, parameters, **kwargs):
self.tracer.debug("enter srServiceStateChanged hook; %s"
% locals())
# Access to parameters dictionary
hostname = parameters['hostname']
service = parameters['service_name']
port = parameters['service_port']
status = parameters['service_status']
timestamp = parameters['timestamp']
self.tracer.info("leave srServiceStateChanged hook")
return 0
Playlist
On the SAP HANA Academy, there is a full playlist covering all aspects of system replication:
Documentation
For more information see:
SAP Help Portal
- What’s New in the SAP HANA Platform 2.0 (Release Notes) – SAP HANA High Availability (New and Changed) – SAP HANA Release Notes
- High Availability for SAP HANA – SAP HANA Administration Guide
- Active/Active (Read Enabled) – SAP HANA Administration Guide
- Connecting Using Active/Active (Read Enabled) – SAP HANA Administration Guide
- Hint-Based Statement Routing for Active/Active (Read Enabled) – SAP HANA Administration Guide
- SAP HANA System Replication Configuration Parameters (datashipping_parallel_channels) – SAP HANA Administration Guide
- Hook Methods (srServiceStateChanged) – SAP HANA Administration Guide
SAP Notes
- 2404375 – SAP HANA Platform 2.0 SPS 01 Release Note
- 2422689 – SAP HANA 2.0 SPS 01 Database Revision 010
- 2369981 – Required configuration steps for authentication with HANA System Replication
- 2407186 – How-To Guides & Whitepapers For SAP HANA High Availability
White Paper
- Introduction to High Availability for SAP HANA
- Protect Enterprise Readiness with the High Availability Features of SAP HANA
SAP HANA Blogs
- Transforming Database Management with the new SAP HANA 2 feature, Active/Active read-enabled
- Replication setup using HANA cockpit 2.0 and testing Active/Active Read Enable
Thank you for watching
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.
For the full library, see SAP HANA Academy Library – by the SAP HANA Academy.
For the full list of blogs, see Blog Posts – by the SAP HANA Academy.
- Subscribe to our YouTube channel for updates
- Join us on LinkedIn: linkedin.com/in/saphanaacademy
- Follow us on Twitter: @saphanaacademy
- Google+: plus.google.com/+saphanaacademy
- Facebook: facebook.com/saphanaacademy
How is the (read) load distribution between both HANAs done, if neither dedicated connections to the secondary HANA nor hints within the SQL-statements are used? e.g. round robin or per CPU load.
I would like to have DB connections only to the primary HANA (to avoid development effort in the applications) but using the compute power of both.
Hi Daniel,
There is no load-balancing mechanism. The (configuration of the) application controles which read statements are executed where.
Regards,
Denys / SAP HANA Academy
Subscribe to our YouTube Channel
Join us on LinkedIn
Follow us on Twitter
Github code samples
FacebookGoogle+