SAP HANA System Replication (HSR) versus SAP Replication Server (SRS)
1 like3,387 views
This document provides information about SAP HANA System Replication (HSR) and compares it to SAP Replication Server (SRS). HSR replicates transaction log entries from a primary HANA database to secondary databases. It supports synchronous and asynchronous replication and can be used for high availability and disaster recovery. The document outlines the initial setup process and ongoing administration of HSR configurations.
Ad
More Related Content
What's hot (20)
Similar to SAP HANA System Replication (HSR) versus SAP Replication Server (SRS) (20)
Ad
More from Gary Jackson MBCS (19)
Ad
Recently uploaded (20)
![Get & Download Wondershare Filmora Crack Latest [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250429170801-59e1b240-thumbnail.jpg?width=560&fit=bounds)
SAP HANA System Replication (HSR) versus SAP Replication Server (SRS)
- 1. SAP HSR versus SRS
- 2. Automation Core • Technology improvements mean computing tasks previously requiring interaction with people, can be fully automated. • Automation brings repeatability, reduced error rates, easy scalability of service provision. Platform Agnostic • Future interoperability and open standards will mean businesses can swap easily between cloud providers. • It is key that solutions are designed to operate in such a platform agnostic manner outside the bounds of normal technical architecture design (i.e. no fixed O/S choices or fixed DB platforms). Established Technological Principals • Solutions today, should be built using already established technological principals. • Using bleeding edge rarely produces the perceived benefits in places such as core business systems, without significant buy-‐in from business leaders. • Pre-‐empting standards not already widely adopted, could produce a “Beta-‐Max” scenario. Future Assurance • Technology solutions should deliver for a minimum timeframe within the context of the lifecycle of the related business system. • Example: Re-‐writing scripts during any platform migration should not just use the coolest scripting language, they should use a commonly known language widely used and understood. Aliter Consulting Drivers
- 3. • Specific to SAP HANA. • Involves replication of HANA transaction log data from source to a secondary or tertiary database (in “log replay” mode). • Two architecture options: Multi-‐Target (mainly for DR) & Multi-‐Tier (mainly for HA as only 1 mode of replication for all participants). • Primary & secondary DB is the same database (layout, size, blocks). • Multiple replication options: sync, sync-‐mem, async. • Supports active-‐active (read-‐only on secondary). • Supported on Microsoft Azure. • Recommended option for HANA database replication. • Recommended option for DR in Azure with Reserved Instances. • Backups of secondary (or tertiary) databases are not possible. • Setup through HANA Cockpit, HANA Studio or command line. • Administered through HANA Cockpit, HANA Studio or command line. • Monitored in HANA Cockpit, HANA Studio, command line or DBA_COCKPIT. About SAP HANA System Replication
- 4. • Replication of transaction log entries. • Replication from Primary to Secondary (multi-‐target & multi-‐tier). • Replication from Secondary to Tertiary (DR) (multi-‐tier). • Replication from Primary to Tertiary (DR) (multi-‐target). • All data pages/blocks are the same initially (same database). Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 HANA2HANA1 HANA3DB replication Pages Log1… Log2… Log3… Transaction log entries. Multi-‐Target (Primary -‐> Secondary can use SYNC then Secondary -‐> Tertiary can use ASYNC) Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03HANA2HANA1 HANA3DB replication Multi-‐Tier (Primary -‐> Secondary can use SYNC then Secondary -‐> Tertiary must also use SYNC) ! Important ! • Multi-‐Target = can use diff rep modes. • Multi-‐Tier = must use same rep mode. Tier 1 Tier 2 Tier 3 Pages Pages About SAP HANA System Replication
- 5. Multi-‐Target: -‐ Primary (source) replicates to multiple target systems. -‐ Each target can be replicated using different replication modes (e.g. SYNC/ASYNC etc). Multi-‐Tier: -‐ Primary (1st Tier) replicates to secondary (2nd Tier), which can replicate to tertiary (3rd Tied). -‐ All tiers must use same replication mode (e.g. SYNC or ASYNC or … etc). HSR Multi-‐Architecture
- 6. Stage 1: Initialise secondary database. • Initial data shipment over the network. or • (a/b) Initial backup/restore to disk. Stage 2: Replication of transaction log (“log replay”). Stage 3: Add 3rd database. • Initial data shipment over the network. Or • Backup/restore to disk. Stage 4: Replication of transaction log (“log replay”). Azure Subscription -‐ Primary Primary Azure Region d01 d02 HANA2HANA1 Initial Backup/Restore Log shipping #1a #1b #2 #1 ! Important ! • Network bandwidth. • I/O write times on secondary (data disk). • Duration of backups. Azure Subscription -‐ Secondary Secondary Azure Region d03 HANA3 Multi-‐Target Example #3 #3a Log shipping #4 HSR Initial Setup
- 7. Stage 1: Patch / upgrade tertiary (& secondary) databases, start at end of replication chain. Stage 2: Failover from primary to secondary (already patched). Stage 3: Patch old primary (now secondary). Stage 4: Fail-‐back when convenient. ! Important ! • No DB backups of secondary/tertiary. • Patching duration. • Failover duration. Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 HANA2HANA1 HANA3DB replication Patch / Upgrade #1a Patch / Upgrade #1b Patch / Upgrade #3 #2a Multi-‐Target Example HSR Patching & Upgrade
- 8. Fail primary to secondary: New primary replicates to new secondary & old tertiary: Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 HANA2HANA1 HANA3DB replication Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 HANA2HANA1 HANA3DB replication New Primary Multi-‐Target Example HSR Failover (HA/DR)
- 9. • Not database specific (supports SAP ASE, SAP HANA, Oracle, SQLAnywhere). • Replication of “transactions” packaged from SQL DDL/DML changes from source DB to a secondary or tertiary (companion) database. • Primary & secondary DB is NOT the same database (layout, size, blocks). • Multiple replication options: sync, async. • Multiple integration/expansion options for the “queues” e.g. separate VMs. • Does not support active-‐active (read-‐only standby). • Supported on Microsoft Azure. • Recommended option for SAP ASE database replication. • Recommended option for DR of ASE in Azure with Reserved Instances. • Backups of secondary (or tertiary) databases are recommended (to prevent issues during secondary failure). • Backups of SRS “queues” are recommended (depends on latency). • Setup through command line. • Administered through command line. • Monitoring possible in DBA_COCKPIT. • DR node (tertiary database) supported from ASE 16.03. About SAP Replication Server
- 10. • Architecture changed slightly in ASE 16.0 & SRS 16.0 • ASE 16.02 supports only a single companion database. • ASE 16.03 supports companion plus a DR node (tertiary database). • Queues changed slightly in ASE 16.0 to be file-‐system based (SPQ -‐ simple persistent queues). • Software changed slightly in ASE 16.0 so SRS is now embedded with ASE (for BS) binaries. • Software patching process changed slightly in SRS 16.0 as binaries integrated with ASE binaries, so all patched together from Hostagent. • Later Hostagents can now query SRS replication status directly (via DM Agent). About Changes in SRS 16.0
- 11. • Replication of transactions (packaged up). • Replication from primary to standby. • Replication from primary to tertiary. • All databases are physically different. Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 ASE2ASE1 ASE3DB replication SRS1 SRS2 SRS3 Pages insert… update… delete… Pages Pages Transaction package. About SAP Replication Server
- 12. Stage 1: Initial backup/restore to “disk” (materialisation). Stage 2: Replication of transaction packages. Stage 3: Add DR node (tertiary database). Azure Subscription -‐ Primary Primary Azure Region d01 d02 ASE2ASE1SRS1 SRS2 ! Important ! • Disk I/O on backup disk. • Network bandwidth. • I/O write times on secondary (data disk). • Duration of backups. • Duration of restores. Initial Backup/Restore #1a #1b #2 Azure Subscription -‐ Secondary Secondary Azure Region d03 ASE3SRS3 #3 Materialisation SRS Initial Setup
- 13. Stage 1: Patch / upgrade tertiary database. Stage 2: Patch Primary SRS (unused in normal operation). Stage 3: Failover from primary to secondary. Stage 4: Patch secondary SRS (now primary). Stage 5: Patch (old) primary ASE. Stage 6: Failover from secondary to (old) primary. Stage 7: Patch secondary ASE. Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 ASE2ASE1 ASE3DB replication SRS1 SRS2 SRS3 ! Important ! • Patching duration. • Failover duration. ASE Patch / Upgrade #1 AE Patch / Upgrade #7 ASE Patch / Upgrade #5 #3 ! Important ! • SRS is patched on LIVE primary as it is inactive! #2 Patch LIVE! #4 #6 Patch SRS Patching & Upgrade
- 14. Fail primary to secondary: Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 ASE2ASE1 ASE3DB replication SRS1 SRS2 SRS3 Azure Subscription -‐ SecondaryAzure Subscription -‐ Primary Primary Azure Region Secondary Azure Region d01 d02 d03 ASE2ASE1 ASE3DB replication SRS1 SRS2 SRS3 SRS on old primary is now active and new secondary ASE replicates to SRS1 and SRS3, SRS on new primary is inactive (path de-‐active): New Primary Primary SRS Failover (HA/DR)
- 15. • SRS is far more flexible and supports different DB vendors. • Cost of SRS is inherently less as it’s not in-‐memory. • However, SRS incurs higher patching effort compared to HSR. • HSR patching frequency will be higher (for HANA support requirements). • HSR has other abilities (such as re-‐using DR node as Test system host). • SRS administration is mainly command line driven. Summary
- 16. SAP Notes: • SAP Note 1999880 “FAQ: SAP HANA System Replication” v154 • SAP Note 1891560 “SYB: Disaster Recovery Setup with SAP Replication Server” v65 SAP SRS Guides: • SAP SRS 3rd Node (DR node or “Companion Node”): https://help.sap.com/viewer/38af74a09e48457ab699e83f6dfb051a/16.0.3.5/en-‐ US/6ca81e90696e4946a68e9257fa2d3c31.html • Performing a rolling upgrade with DR node: https://help.sap.com/viewer/38af74a09e48457ab699e83f6dfb051a/16.0.3.5/en-‐ US/57c39954b2aa4a5ca6e1da46935ec9d7.html SAP HANA System Replication Guides: • SAP HANA System Replication: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-‐ US/b74e16a9e09541749a745f41246a065e.html • SAP HANA System Replication Multi-‐target: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-‐ US/ba457510958241889a459e606bbcf3d3.html • SAP HANA System Replication Multi-‐Tier: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-‐ US/ca6f4c62c45b4c85a109c7faf62881fc.html References
- 17. Thank You