HANA System Replication (HSR): Architecture, Modes & Step-by-Step Setup
A comprehensive operational handbook for SAP HANA System Replication (HSR), detailing Replication Modes (sync, syncmem, async, full sync), Operation Modes (logreplay, delta_datashipping), hdbnsutil CLI setup, network routing, and takeover/failback procedures.
Advanced (Senior DBA)HSR & High Availability~22 min studyHANA 2.0 (All SPS)
Core Learning Objectives
- 1.Master the 4 Replication Modes and their network latency vs. data loss trade-offs.
- 2.Understand the 3 Operation Modes, focusing on logreplay and secondary read access.
- 3.Configure HSR from scratch using hdbnsutil commands on primary and secondary nodes.
- 4.Resolve hostname resolution and dedicated replication network routing in global.ini.
- 5.Execute a Planned Takeover and Unplanned Emergency Failover with zero split-brain risk.
Prerequisites:hana-architecture-services-overviewhana-internals-persistence-savepoints
Definition & Architectural Rationale
Technical Definition:
SAP HANA System Replication (HSR) is a native high availability and disaster recovery feature that continuously ships transactional redo log buffers and persistence deltas from an active primary HANA system to one or more secondary standby systems.
Why this component exists:
Traditional disk or snapshot replication incurs latency and requires lengthy database startup and crash recovery upon failover. HSR maintains standby database processes actively loaded in memory on the secondary site, reducing failover time (RTO) to seconds while guaranteeing zero data loss (RPO = 0 in sync modes).
Internal Working & Mechanics
1. Replication Modes:
- synchronous (sync): Primary sends log buffer to secondary. Primary waits for secondary to write buffer to DISK before committing. RPO = 0. Highest commit latency penalty.
- synchronous in memory (syncmem): Primary sends log buffer. Primary commits as soon as secondary acknowledges receiving the buffer into its RAM log buffer. RPO = 0 (unless both sites lose power simultaneously). Lower latency than sync.
- asynchronous (async): Primary commits immediately without waiting for secondary acknowledgement. Redo logs are buffered and shipped over network. Zero performance impact on primary. RPO > 0 (potential slight data loss during unexpected crash). Best for long-distance DR (>100 km).
- full sync: Extension of sync. If network connection to secondary drops, primary HALTS transaction processing rather than falling back to standalone mode, guaranteeing zero data divergence.
2. Operation Modes:
- delta_datashipping: (Legacy / Default in HANA 1.0): Ships redo logs continuously, plus periodic delta data snapshots (every 10 minutes) from data volumes. Secondary indexserver is NOT actively replaying logs in memory. Long failover time.
- logreplay: (Standard in HANA 2.0): Initial full data snapshot is transferred once; thereafter, ONLY redo logs are shipped. The secondary indexserver continuously replays redo logs into its memory tables in real time! Failover takes seconds (RTO < 60s).
- logreplay_readaccess: Secondary database allows read-only analytical queries on active tables (Active/Active Read-Enabled).
3. Dedicated Replication Network & global.ini:
Replication traffic can saturate standard 1 GbE management networks. SAP best practice mandates a dedicated 10/25/40 GbE network. Map internal virtual hostnames in global.ini:
[system_replication_hostname_resolution]
192.168.20.10 = site-primary
192.168.20.20 = site-secondary
[system_replication_communication]
listeninterface = .internal
Architecture Flow Diagram
Mermaid DiagramHANA System Replication (HSR): Architecture, Modes & Step-by-Step Setup
Architectural Flow: Transactions commit on the primary while the HSR engine simultaneously ships redo log buffers over a dedicated network. In logreplay mode, the secondary indexserver continuously replays changes into its in-memory tables.
Linux Terminal Diagnostics & Operations
Enable System Replication on Primary Site (hdbnsutil -sr_enable)
user: <sid>adm
Configures primary Name Server as the master replication site.
hdbadm@host $ hdbnsutil -sr_enable --name=SITE_PRI
Terminal Standard Output (stdout):
nameserver is active, proceeding ... validating topology ... enabling system replication ... system replication successfully enabled.
Output Analysis: Primary site is now primed to accept secondary registration connections.
Register Secondary Site with Primary (hdbnsutil -sr_register)
user: <sid>adm
Connects secondary node to primary and initiates initial data transfer.
hdbadm@host $ hdbnsutil -sr_register --remoteHost=site-primary --remoteInstance=00 --replicationMode=syncmem --operationMode=logreplay --name=SITE_SEC
Terminal Standard Output (stdout):
adding site ... nameserver is not running, proceeding ... updating topology ... registering at remote site site-primary ... site registered successfully.
Output Analysis: Secondary successfully registered in SYNCMEM mode with logreplay. Now ready to be started via HDB start.
Verify HSR Synchronization State (hdbnsutil -sr_state)
user: <sid>adm
Checks connection state, mode, and whether secondary is fully synchronized.
hdbadm@host $ hdbnsutil -sr_state
Terminal Standard Output (stdout):
System Replication State ~~~~~~~~~~~~~~~~~~~~~~~~ mode: PRIMARY site id: 1 site name: SITE_PRI Host Mapping: ~~~~~~~~~~~~~ site-primary -> site-secondary Secondary Sites: ~~~~~~~~~~~~~~~~ site id: 2 site name: SITE_SEC process: hdbnsutil active: YES mode: syncmem operation mode: logreplay mapping: site-primary -> site-secondary status: ACTIVE overall replication status: ACTIVE
Output Analysis: HSR status is ACTIVE; secondary is active (YES) in syncmem mode with logreplay operation mode.
Execute Takeover on Secondary Site (hdbnsutil -sr_takeover)
user: <sid>adm
Promotes the secondary standby site to become the active primary database during planned maintenance or disaster failover.
hdbadm@host $ hdbnsutil -sr_takeover
Terminal Standard Output (stdout):
nameserver is active, proceeding ... taking over system ... stopping system replication ... resetting topology ... takeover completed successfully.
Output Analysis: Secondary has assumed the PRIMARY role. Ports 30015/30013 are now open for read/write client transactions.
Troubleshooting & Root Cause Analysis
Production Best Practices & Operational Risks
Mandatory Best Practices
- Always configure a dedicated, non-routed physical replication network (10 GbE+) to prevent replication traffic from contending with application users.
- Use Linux HA cluster managers (SUSE Linux Enterprise High Availability Extension or Red Hat High Availability) with STONITH fencing agents to automate failover and prevent split-brain scenarios.