Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

SAP HANA system replication

10 min

Listen to this lesson

0:00 / 7:55

SAP HANA system replication (HSR) is SAP HANA's built-in way to keep a second database, the secondary, in step with the primary. After an initial full copy of the data, the primary continuously ships its redo log to the secondary. If the primary fails, an administrator or a cluster performs a takeover, and the secondary becomes the new primary. The same mechanism serves HA (a secondary nearby) and DR (a secondary far away), with different settings.

  1. EnableReplication enabled on the primary with a unique site name; a valid backup must exist
  2. RegisterSecondary registered with replication mode and operation mode
  3. Initial syncFull data copied; then the log is shipped continuously
  4. In syncStatus shows active; secondary ready for takeover
  5. TakeoverSecondary becomes primary after a failure or a planned switch
  6. Re-registerFormer primary registered as the new secondary and resynchronized
The life cycle of a system replication pair. Commands and details depend on the SAP HANA revision.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-303

Replication modes

ModeWhen the primary confirms a commitTypical use
SYNCAfter the secondary has received the log and written it to diskHA within a site or between nearby zones; data loss close to zero
SYNCMEMAfter the secondary has received the log in memoryHA where slightly less protection is traded for lower commit latency
ASYNCWithout waiting for the secondaryDR over long distances, where waiting would slow every transaction; some data loss possible

Replication modes in simplified form. Check SAP HANA documentation for your revision, including the optional full-sync setting.

What a commit waits for in each replication mode: protection is bought with commit latency.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-303

The mode is a business decision disguised as a technical parameter. Synchronous modes make each commit wait for the network round trip, which is fine over short distances and painful over long ones. Asynchronous replication keeps commits fast but means the last transactions before a disaster may never reach the secondary. Cluster software that automates takeover typically requires a synchronous mode; one SUSE best-practice guide for SAP HANA system replication states that ASYNC is not supported with automated cluster takeover.

Operation modes and takeover readiness

  • logreplay: the secondary continuously replays the log, acting as a hot standby. This is the preferred mode for HA.
  • logreplay_readaccess: like logreplay, plus read-only access on the secondary (Active/Active read-enabled), so reporting can run there.
  • delta_datashipping: the original mode, now considered legacy.
  • Preload: a secondary that preloads tables into memory takes over in a short time; a cost-optimized secondary that runs other workloads with preload switched off takes longer.
Primary (zone A)CMP production database; users and jobs work here
Secondary for HA (zone B, same region)Synchronous replication, logreplay, preloaded; cluster-controlled takeover
Tertiary for DR (other region)Asynchronous replication; takeover only after a declared disaster or in a DR test
A common pattern: synchronous HA nearby plus asynchronous DR far away. Contoso's actual design is defined in its RISE contract.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-303

A takeover moves the database role, but users still have to reach the system. The application servers must connect to the new primary, usually through virtual host names or redirected DNS entries; SAP's R&R describes the DR test failover as covering the database, the application and the cnames. Interfaces, printers and RFC partners outside the landscape may hold their own addresses, which is why customer-side DR procedures matter.

After a takeover, internal connections follow the virtual names, but partners that hold their own addresses need the customer's DR procedure.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-303

Watch replication health every day, not only during tests. A secondary that has silently fallen out of sync gives no protection, and a takeover to a secondary that is hours behind turns an HA event into data loss. Under RISE, SAP monitors replication as part of the contracted HA and DR services; Contoso should still ask to see the status in its regular service reviews and include replication state in the readiness checks before any planned maintenance or test.

What would you do?

Contoso's architect proposes synchronous replication to a DR site 1,100 km away so that a disaster loses no data. Sam is asked for his view. What should he say?

Key points
  • HSR ships the redo log from primary to secondary; takeover makes the secondary the new primary.
  • SYNC waits for the secondary's disk, SYNCMEM for its memory, ASYNC for nothing: protection versus latency.
  • logreplay is the preferred HA operation mode; logreplay_readaccess adds read access on the secondary.
  • Takeover also needs application connections, virtual names and interfaces to follow.

Check your understanding · not graded

Lesson check

  1. 1. In SYNC mode, when does the primary confirm a commit?

  2. 2. Why is ASYNC typically used for long-distance DR?

  3. 3. Which operation mode adds read-only access on the secondary?

  4. 4. After a database takeover, why might users still not reach the system?