SAPHanaSR_multi-target(7)

📦 version 1.3.4, in opensuse-leap 16.0

🦋 NAME 🦋

Okay bestie, so this whole page is SAPHanaSR_multi-target(7) — it lives in the SAPHanaSR-angi manual, and it's literally all about SAPHanaSR multi-target system replication scenarios. That's the entire vibe. 💅

✨ DESCRIPTION ✨

So here's the tea: if you've got more than one HANA secondary site connected by system replication to one same primary — congrats, that's HANA multi-target system replication. 🌈

But pay attention, because this is the part people fumble: in any case, only two HANA sites, connected with one system replication, are controlled by one Linux cluster. That's the rule, no cap. 👑

A third HANA site, sitting outside the cluster, might be connected by a second system replication to one of the cluster sites. And then to that third site, a fourth one might be connected. It's giving chain reaction energy, fr fr. 🎀

So the common possible scenarios are literally these:

  • Scale-up perf-opt with multi-target replication — [ A <= B' ] -> C
  • Scale-up perf-opt with multi-tier replication (directed replication chain) — [ A' => B ] -> C
  • Scale-up cost-opt with multi-target replication — [ "Q,A <= B' ] -> C
  • Scale-up perf-opt with multi-target replication and fourth site — [ A <= B' ] -> C => D
  • Scale-out perf-opt ERP-style with multi-target replication — [ Aa <= 'Bb ] -> Cc
  • Scale-out perf-opt ERP-style with multi-target replication and fourth site — [ Aa <= 'Bb ] -> Cc => Dd

If that notation is looking like a whole foreign language to you (same, honestly), please refer to manual page SAPHanaSR-angi-scenarios(7) — it decodes the whole scenario notation thing for you. 🧚

🌸 the DR site situation 🌸

The third site is often used as a Disaster Recovery (DR) site, and it's a longer distance away. So the replication mode might be async. Highkey important: the third site needs to be registered to the HANA primary site inside the Linux cluster. 🔥

And the decision and procedure for takeover to outside of the Linux cluster in DR case — those have to be prepared carefully, bestie, and should be trained on regular base. Like, actually practice it. Don't just write it down and hope. 😭

This is the kind of thing that eats you alive at 3am if nobody ever rehearsed it. Prepare it properly. 💀

🍓 the temporary replication situation 🍓

Another case is a temporary replication — e.g. for filling test databases or performing an upgrade. In that case the third site might be registered to either site of the Linux cluster. ✨

But watch out: if the third site is registered to the secondary site of the Linux cluster and that secondary site fails, manual intervention is necessary at third site. Not automatic. You. Manually. At the third site. 🙈

⭐ how the cluster actually notices any of this ⭐

The Linux cluster recognises the status of the second replication by the HANA HA/DR provider hook event srConnectionChanged() on the primary site (master) node. See susChkSrv.py(7) for the details, iykyk. 🫶

And the third replication link? It's straight-up invisible for the Linux cluster. 👀 However — it is shown by systemReplicationStatus.py at the primary site. So the cluster doesn't see it, but you can. 🦋

✨ EXAMPLES ✨

Okay so these examples are giving highlevel procedures plus the basic tasks you'll actually be doing, bestie. Detailled runbooks can be created by using the appropriate tasks for adding details to the procedures. 💅

  • Procedure for connecting a third site by replication to a cluster-controlled HANA pair.

Details on how to perform the steps can be found in additional examples below.

  1. Collect information and prepare parameter sheet.
  2. Set up the third site.
  3. Add the register secondaries setting to the cluster-controlled HANA databases.
  4. Copy HANA secure keystore from current primary to third site.
  5. Register the third HANA database to the current primary.
  6. Check the new replication.
  7. Check if cluster takeover still works, and third site follows.
  • Procedure for connecting a fourth site by replication to a third site.

Details on how to perform the steps can be found in additional examples below.

  1. Collect information and prepare parameter sheet.
  2. Set up the fourth site.
  3. Copy HANA secure keystore from current primary to fourth site.
  4. Back up the third HANA database and enable system replication.
  5. Register the fourth HANA database to the third.
  6. Check the new replication.
  • Procedure for disconnecting a temporarily connected third site while primary is available.

Details on how to perform the steps can be found in additional examples below.

  1. Collect information and prepare parameter sheet.
  2. Disable system replication at third site.
  3. Remove orphaned attributes from CIB.
  4. Check if cluster-controlled replication still works.
  • Procedure for taking over to third site in DR case.

Make sure to check for sane and idle status of Linux cluster and HANA before and after each step. Details on how to perform the steps can be found in additional examples below and in manual page SAPHanaSR_maintenance_examples(7). See also SAP note 2517805.

Note: Understand the impact before trying. 👀
  1. Collect information and prepare parameter sheet.
  2. Make sure both sites of the Linux cluster are not running.
  3. Take decision for takeover to third site.

The next steps will invalidate all HANA data at former production sites. 😭

  1. Perform takeover at third site.
  2. Activate IP address at third site (master) node.
  • Procedure for taking back from third site to Linux cluster.

Automatic start-up of cluster has to be disabled at production site nodes. Nodes are up and OS is running at former production site, Linux cluster and HANA are down. Third site is up and running with system replication enabled. All site names have to be same as already known to the cluster. Example for scale-up. Make sure to check for sane and idle status of Linux cluster and HANA before and after each step. Details on how to perform the steps can be found in additional examples below and in manual page SAPHanaSR_maintenance_examples(7).

site1, node1: former production primary, currently down
site2, node2: former production secondary, currently down
site3, node3: current primary, with production IP address
site4, node4: current secondary (optional)
Note: Understand the impact before trying. 👀
  1. Collect information and prepare parameter sheet.

The next steps will overwrite all HANA data at former production sites. 💀

  1. Register former production primary as secondary to current primary at DR site.
  2. Start former production primary as secondary.
  3. Enable system replication at former production primary.
  4. Register former production secondary to former production primary again.
  5. Start former production secondary.
  6. Stop and unregister fourth site (if existing).
  7. Takeover at former production primary, suspend primary at DR site.
  8. Remove IP address from current primary at DR site.
  9. Set IP address at new production primary.
  10. Start Linux cluster at new production primary only.
  11. Set multi-state SAPHanaController resource into maintenance.
  12. Start Linux cluster at production secondary.
  13. Refresh multi-state SAPHanaController resource.
  14. Get multi-state SAPHanaController resource out of maintenance.
  15. Check everything is fine.

The next steps will overwrite all HANA data at third site. 💀

  1. Register online the third site to primary.
  2. Enable system replication at third site (if needed for fourth site).
  3. Register fourth site to third and start site (if needed).
  4. Check everything is fine.
  • Disabling automatic cluster start at system boot.

Needs to be done at all Linux cluster nodes, if third site outside the cluster should be used as DR site. 🫶

# systemctl disable pacemaker
# systemctl disable corosync
# systemctl status pacemaker
# systemctl status corosync
  • Entry in global.ini to register secondaries on takeover.

This entry is needed at all HANA nodes of the Linux cluster to allow the SAPHanaController parameter AUTOMATED_REGISTER=true in multi-target environments. The HANA has to be stopped before the file can be edited. Do not copy the file global.ini between nodes. Please check SAP HANA documentation for details.

[system_replication]
 ...
register_secondaries_on_takeover = true
 ...
  • Copying the HANA secure keystore from primary to third site.

Needs to be done before registering the third site. Third site node is node3, SID is HA1. 🔐

# cd /usr/sap/HA1/SYS/global/security/rsecssfs
# md5sum */*
# rsync -va * node3:$PWD/
# ssh node3 "md5sum $PWD/*/*"
  • Registering third site as additional secondary to production primary.

Needs to be done at third site (master) node. Third site is site3, production primary is node1, SID is HA1, instance number is 00, replication mode is async, operation mode is logreplay. 🦋

# su - ha1adm
~> HDB info
~> hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=00 \
 --replicationMode=async --operationMode=logreplay \
 --force_full_replica --online --name=site3
~> hdbnsutil -sr_state
  • Checking srHook attribute for third site.

Could be done at any cluster node once a third site has been connected. The susHanaSR.py HA/DR provider hook script of the cluster-controlled HANA databases will detect the outer system replication and write a related srHook attribute into CIB. The srHook attributes have to be distinguished by site names. The two production sites are site1 and site2 the third (e.g. DR) site is site3. See also susHanaSR.py(7) and SAPHanaSR-showAttr(8). 👑

# crm configure show SAPHanaSR | \
 grep -e _srHook_site1= -e _srHook_site2= -e _srHook_site3=
# SAPHanaSR-showAttr
  • Backing up third site HANA and enabling system replication.

Needs to be done at third site (master) node before registering fourth site. SID is HA1, instance number is 00, site name is site3.

# su - ha1adm
~> hdbsql -i 00 -u SYSTEM -d SYSTEMDB \
 "BACKUP DATA FOR FULL SYSTEM USING FILE ('backup')"
~> hdbnsutil -sr_enable --name=site3
~> hdbnsutil -sr_state
  • Disabling system replication at third site while source is available.

To be done at third site (master) node. Replication source needs to be up and running. In case fourth is connected to third, that replication will be removed as well. SID is HA1. 🧚

# su - ha1adm
~> hdbnsutil -sr_state
~> hdbnsutil -sr_unregister --force
~> hdbnsutil -sr_state
  • Taking over at third site when source is not available.

To be done at third site (master) node. Replication source is not available. In case fourth is connected to third, that replication will stay. SID is HA1.

# su - ha1adm
~> hdbnsutil -sr_stateConfiguration
~> hdbnsutil -sr_takeover
~> hdbnsutil -sr_state
~> cdpy; python3 ./systemReplicationStatus.py; echo rc:$?
  • Removing orphaned srHook attribute from CIB.

Might be done at any cluster node once a temporary replication has been finally disabled. To be removed srHook´s SID is ICE, site is BERG.

Note: Understand the impact before trying. 👀
# crm configure show SAPHanaSR | grep _srHook_BERG=
# crm_attribute -n hana_ice_site_srHook_BERG -t crm_config \
 -s SAPHanaSR --delete
# crm configure show SAPHanaSR | grep _srHook_BERG=
  • Checking status of all system replication connections.

Could be done at primary site (master) node. SID is HA1. See also SAPHanaSR_maintenance_examples(7) and susHanaSR.py(7). 🎀

# su - ha1adm
~> cdpy; python3 ./systemReplicationStatus.py; echo rc:$?
  • Cleaning up HANA transaction log tables.

Might be done after replication outside the Linux cluster has been interrupted and got working again. SID is HA1, instance number is 00.

# su - ha1adm
~> hdbsql -i 00 -u SYSTEM "ALTER SYSTEM RECLAIM LOG;"

📁 FILES 📁

  • /hana/shared/$SID/global/hdb/custom/config/global.ini — on-disk representation of HANA global system configuration.
  • /usr/sap/$SID/SYS/global/security/rsecssfs/ — HANA database secure keystore directory.

✅ REQUIREMENTS ✅

Okay so these are non-negotiable, bestie — no cap. 🌈

  • Only one system replication between the two SAP HANA databases in the Linux cluster. Maximum one system replication to an HANA database outside the Linux cluster.
  • The replication mode is either sync or syncmem for the controlled replication. Replication mode async is not supported inside the Linux cluster.
  • Once an HANA system replication site is known to the Linux cluster, that exact site name has to be used whenever the site is registered manually. At any time only one site is configured as primary replication source.
  • No Multi-SID scenario.
  • "register_secondaries_on_takeover = true" is needed at all HANA sites of the Linux cluster.
  • All HANA sites inside and outside the Linux cluster need to have the same content in their HANA secure keystore.
  • Sufficient disk space for transaction logs and log backup at each potential replication source. Housekeeping might also help.
  • The Linux cluster has no control over HANA system replication and HANA landscape status outside the cluster.
  • If the third site is used as DR site, it needs to be registered to the HANA primary site inside the Linux cluster.
  • If the third site is used as DR site, at all production site nodes the automatic start of cluster at boot has to be disabled.
  • If the third site is used as DR site, decision and procedure for takeover are in customer´s responsibility. All need to comply to SAP HANA requirements, please refer to SAP documentation for details.
  • Any manual procedure has to be tested, documented and trained before applied on production systems.

See also the REQUIREMENTS section in manual pages SAPHanaSR(7) and susHanaSR.py(7). 💖

🐞 BUGS 🐞

Okay so if literally anything goes sideways, bestie, do not suffer in silence — use your fave SAP support process and open a request for the component BC-OP-LNX-SUSE. That's the vibe, that's the move. 💅

And for any other feedback or suggestions you've got kicking around in your brain? Send them over to feedback@suse.com. They genuinely wanna hear it. 🫶

👀 SEE ALSO 👀

Like, go read these next, fr fr — they're all part of the same little universe:

That last one is a whole SAP note, and lowkey it's the "am I synced or not" cheat code. iykyk. ✨

💖 AUTHORS 💖

The icons who actually wrote this:

A.Briel, F.Herschel, L.Pinne.

Periodt. 👑

(c) 2026 SUSE LLC

And the serious bit, so listen up: The package SAPHanaSR-angi comes with ABSOLUTELY NO WARRANTY. No cap, zero warranty, none. 😭

For the details, go read the GNU General Public License at http://www.gnu.org/licenses/gpl.html. It's giving very "read the terms" but it matters. 🌸

And that's a wrap on this whole page, bestie 🎀 — it's SAPHanaSR_multi-target(7), dated 12 Feb 2026, and you absolutely ate by making it to the end. Go break nothing, or if you do, you know where BC-OP-LNX-SUSE is. 💜🦋

📦 where this page comes from