susHanaSrMultiTarget.py(7)

📦 version 1.3.4, in opensuse-leap 16.0

💖 susHanaSrMultiTarget.py — the SAPHanaSR-ScaleOut girlie who handles multi-target SAP HANA srHook 💖

okay so bestie, welcome to the manual page for susHanaSrMultiTarget.py from SAPHanaSR-ScaleOut — she's the provider for the multi-target aware SAP HANA srHook method srConnectionChanged(). buckle up, she's iconic and also kind of a lot 💅

✨ NAME ✨

susHanaSrMultiTarget.py — Provider for multi-target aware SAP HANA srHook method srConnectionChanged().

🌸 DESCRIPTION 🌸

so susHanaSrMultitarget.py can be used to provide a script for the SAP HANA srHook method srConnectionChanged(). that's the whole gig, and she ate 🎀

the SAP HANA nameserver hands out a Python-based API (the "HA/DR providers"), and that API gets called at the big moments of the host auto-failover and system replication takeover process. these so-called hooks are literally just there so you can run arbitrary operations that need to be executed. the method srConnectionChanged() gets called on the master nameserver the instant one of the replicating services loses or establishes the system replication connection. and fun fact: this method is called only once. no cap, one time 🫶

the SAPHanaSR srHook script and the resource agent need to use the same cluster attributes — they're matching, they're coordinating, they're that duo. so therefore, beginning with package SAPHanaSR-ScaleOut version 0.180, a generation attribute is used. slay ✨

🦋 SUPPORTED PARAMETERS 🦋

  • the "HA/DR providers" API accepts the following mandatory parameters for the ha_dr_provider_saphanasrmultitarget section:
[ha_dr_provider_sushanasrmultitarget]

provider = susHanaSrMultiTarget

path = /usr/share/SAPHanaSR-angi/

execution_order = [ INTEGER ]

plus one optional parameter can be used to control which attributes the srHook script should access in the Linux cluster CIB. bestie listen to me: the following parameter should be set only if requested by support engineers. the default is sufficient for normal operation, fr fr 🙈

cib_access = [ all-on | site-on ]

the "HA/DR providers" API also accepts the following optional parameter for the system_replication section:

[system_replication]

register_secondaries_on_takeover = [ true | false ]

and the "HA/DR providers" API accepts the following mandatory parameter for the trace section:

[trace]

ha_dr_saphanasrmultitarget = [ info | debug ]
  • the SAPHanaController RA recognizes the effecting system replication status via attributes in the CIB properties section. the SAP System Indentifier (sid) is given in lower case — lowercase only, she's lowercase 💅 see the REQUIREMENTS section below for supported API versions and scenarios. for SAPHanaSR-angi, the susHanaSrMultiTarget.py provides site-specific attributes among the SAPHanaSR properties:
hana_<sid>_site_srHook_<site> = [ SOK | SFAIL | SWAIT | SREG | SCOPY | PRIM ]
note: see SAPHanaSR.py(7) for old-style SAPHanaSR-ScaleOut with one global attribute instead of site-specific attributes. different era, different vibe 👑
  • the SAPHanaSR-manageAttr tool recognises scale-out multi-target capability via host attribute. the SAP System Indentifier (sid) is given in lower case. see the REQUIREMENTS section below for supported API versions and scenarios. for new SAPHanaSR-angi, the susHanaSrMultiTarget.py reports its generation:
hana_<sid>_gsh = [ generation ]

🔥 RETURN CODES 🔥

  • 0 — Successful program execution. she did it, she showed up, she delivered 🌈
  • >0 — Usage, syntax or execution errors. 💀 something went sideways.

🎀 EXAMPLES 🎀

  • Example for generic permission in /etc/sudoers.d/SAPHanaSR . HANA 2.0 Scale-Out, SID is SLE. the attribute contains the lowercase-SID. the main srHook attribute and all auxiliary host- and site-attributes are covered (..._gsh, ..._mts). access should always be limited to the specific SID — don't be giving out blanket permissions, that's not the vibe 🚫
# Comments need a blank after the hash.
# SAPHanaSR needs for srHook:
sleadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_sle_*
  • Example for looking up the sudo permission for the srHook script. all related files (/etc/sudoers and /etc/sudoers.d/*) are scanned. example SID is HA1.
# sudo -U ha1adm -l | grep "NOPASSWD.*crm_attribute.*hana_ha1"
  • Example for entry in SAP HANA 2.0 global configuration /hana/shared/$SID/global/hdb/custom/config/global.ini with multi-target aware, site-specific attributes. this entry is needed at both sites that are managed by the Linux cluster. the HANA has to be stopped before the files can be edited 🛑 do not copy the file between nodes. please check SAP HANA documentation for details. do not forget to adapt the sudo permission, see examples above.
[ha_dr_provider_sushanasrmultitarget]
provider = susHanaSrMultiTarget
path = /usr/share/SAPHanaSR-angi/
execution_order = 1
[trace]
ha_dr_saphanasrmultitarget = info
  • Example for entry in SAP HANA 2.0 global configuration /hana/shared/$SID/global/hdb/custom/config/global.ini to enable a multi-target aware third site. this entry is needed to allow ocf_suse_SAPHanaController(7) parameter AUTOMATED_REGISTER=true in multi-target environments. the HANA has to be stopped before the files can be edited. do not copy the file between nodes. please check SAP HANA documentation for details.
[system_replication]
 ...
register_secondaries_on_takeover = true
 ...
  • Example for entry in SAP HANA 2.0 nameserver configuration /hana/shared/$SID/global/hdb/custom/config/nameserver.ini for two-node scale-out HANA without standby nodes. this entry is needed at both sites that are managed by the Linux cluster. the HANA has to be stopped before the files can be edited. do not copy the file between nodes. it might be necessary to un-register and re-register the secondary to make the change effective on the secondary site 😭 please check SAP HANA documentation for details. in this example the master node is suse11, the worker is suse12.
[landscape]
 ...
master = suse11:31001
worker = suse11 suse12
active_master = suse11:31001
roles_suse11 = worker
roles_suse12 = worker
 ...
  • Example for checking the system log for srHook setting HANA system replication status in the CIB properties section. to be executed on the respective HANA primary site's master nameserver.
# grep "sudo.*crm_attribute.*srHook" /var/log/messages
  • Example for checking the HANA tracefiles for srConnectionChanged() events. to be executed on the respective HANA primary site's master nameserver.
# su - sleadm
~> cdtrace
~> grep susHanaS.*srConnectionChanged.*called nameserver_*.trc
~> grep crm_attribute.*susHanaS nameserver_*.trc
# exit
  • Example for checking the HANA tracefiles for when the hook script has been loaded. to be executed on both sites' master nameservers.
# su - sleadm
~> cdtrace
~> grep HADR.*load.*susHanaS nameserver_*.trc
  • Example for comparing the Linux cluster srHook attribute with the current HANA SR state. SID is HA1. to be executed on the current HANA primary site.
# SAPHanaSR-showAttr | grep -A4 srHook
# su - ha1adm -c "HDBSettings.sh systemReplicationStatus.py"
  • Potentially dangerous example for manually changing the Linux cluster srHook attribute according to the current HANA SR state. this might be desired if the HANA SR state has changed while the Linux cluster was completely down. SID is ICE, site is BERG, current HANA SR state is SFAIL. ⚠️
Note: Understand the impact before trying. like, actually. understand it. 💀
# su - iceadm -c "HDBSettings.sh systemReplicationStatus.py"
# cs_clusterstate -i
# crm_attribute -n hana_ice_site_srHook_BERG -v SFAIL -t crm_config -s SAPHanaSR
# SAPHanaSR-showAttr
  • Example for removing an orphaned global srHook attribute. this might be done after upgrading from old-style srHook, to avoid confusion caused by different HANA HADR provider API versions. see also SAPHanaSR.py(7) and SAPHanaSR-manageAttr(8). SID is HA1.
# SAPHanaSR-showAttr
# cs_clusterstate -i
crm configure show SAPHanaSR
# crm_attribute --delete -t crm_config --name hana_ha1_glob_srHook
crm configure show SAPHanaSR
# SAPHanaSR-showAttr

🧚 FILES 🧚

  • /usr/share/SAPHanaSR-angi/susHanaSrMultiTarget.py — the scale-out multi-target aware hook provider, delivered with the RPM. that's her, that's the main character 👑
  • /hana/shared/$SID/global/hdb/custom/config/global.ini — the on-disk representation of HANA global system configuration
  • /hana/shared/$SID/global/hdb/custom/config/nameserver.ini — the on-disk representation of HANA nameserver configuration
  • /etc/sudoers , /etc/sudoers.d/ — the sudo permission configuration
  • /usr/sap/$SID/HDB$nr/$host/trace/ — the directory with HANA trace files
  • /usr/sap/$SID/HDB$nr/.crm_attribute.$SITE — the internal cache for srHook status changes while the Linux cluster is down. this file is owned and read/write by ${sid}adm and must never be touched 🙅‍♀️ hands off, bestie.

⭐ REQUIREMENTS ⭐

  1. SAP HANA starting with version 1.0 SPS11 patch level 112.02. older versions do not provide the srHook method srConnectionChanged(). with the mentioned HANA versions, uni-directional chained system replication is possible. with HANA 2.0 SPS04 and later, multi-target system replication is possible as well. see also SAPHanaSR-ScaleOut(7) for supported API versions and scenarios.
  2. no other HADR provider hook script should be configured for the srConnectionChanged() method. hook scripts for other methods, provided in SAPHanaSR-angi, can be used in parallel to susHanaSrMultiTarget.py, if not documented contradictingly.
  3. the user ${sid}adm needs execution permission as user root for the command crm_attribute.
  4. the hook provider needs to be added to the HANA global configuration, in memory and on disk (in persistence). both. always both. ✨
  5. the Linux cluster needs to be up and running to allow HA/DR provider events being written into CIB attributes. the current HANA SR status might differ from the CIB srHook attribute after Linux cluster maintenance. so like, don't panic if they're not matching 😭
  6. the srHook script runtime almost completely depends on call-outs to OS and Linux cluster.
  7. running srHook script and RA need to be of the same or compatible generation. this is indicated by node attributes.

🍓 BUGS 🍓

old SAPHanaSR/SAPHanaSR-ScaleOut properties and new SAPHanaSR-angi properties for HANA SR status can not be used at the same time. pick a lane bestie, they do not mix 💀

in case of any problem, please use your favourite SAP support process to open a request for the component BC-OP-LNX-SUSE. please report any other feedback and suggestions to feedback@suse.com. 🫶

🔗 SEE ALSO

Okay bestie, you wanna go deeper? These are literally the sibling pages and the lore drops 🫶 every single one, no skips:

And now the link dump, because the docs are right there and reading them is the vibe check 💅

That one long frameset URL is exactly as written, bestie — don't "clean it up", it's holding the whole navigation together 😭 🔥

👑 AUTHORS

The icons who made this happen, fr fr:

  • A.Briel
  • F.Herschel
  • L.Pinne

main character energy from all three, honestly. ✨

(c) 2020-2026 SUSE LLC

susHanaSrMultiTarget.py comes with ABSOLUTELY NO WARRANTY. Not a single one, no cap 💀

For details see the GNU General Public License at http://www.gnu.org/licenses/gpl.html

Read the license, bestie. It's giving ✨ responsible ✨ and it's literally right there. 🦋

💖 that's the whole page, you made it 💖

This was susHanaSrMultiTarget.py(7) — source and version susHanaSrMultiTarget.py(7), dated 10 Dec 2025. Go forth, slay your cluster, and remember: warranty? absolutely none 💅🌸

📦 where this page comes from