[ClusterLabs] SAPHanaController & SAPHanaTopology question

[Strahil Nikolov]

Thanks Andrei,
so can we assume that killing those processes during NFS umount is acceptable and no risk to the HANA data can be observed ?
I have noticed that the cluster is killing those when the cluster is being stopped (including NFS) .

Best Regards,Strahil Nikolov
 
 
  On Fri, Apr 2, 2021 at 14:31, Andrei Borzenkov<arvidjaar at gmail.com> wrote:   On Fri, Apr 2, 2021 at 12:30 PM Strahil Nikolov <hunter86_bg at yahoo.com> wrote:
>
> To be more specific, the processes left are 'hdbrsutil'

This process holds database content in memory after shutdown (I
believe, for 1 hour by default) to facilitate fast startup. You can
disable it. See SAP note 2159435.


> and the 'sapstartsrv'.
>

Well, this is the primary service that handles all requests from
sapcontrol. It is sort of supposed to be always running. Resource
agent handles missing sapstartsrv during activation.

I guess if you have a valid use case you may try to open a service
request or github issue to also stop sapstartsrv.

> Best Regards,
> Strahil Nikolov
>
> On Fri, Apr 2, 2021 at 12:20, Strahil Nikolov
> <hunter86_bg at yahoo.com> wrote:
> Hello All,
>
> I am testing the newly built HANA (Scale-out) cluster and it seems that:
> Neither SAPHanaController, nor SAPHanaTopology are stopping the HANA when I put the nodes (same DC = same HANA) in standby. This of course leads to a situation where the NFS cannot be umounted and despite the stop timeout  - leads to fencing(on-fail=fence).
>
> I thought that the Controller resource agent is stopping the HANA and the slave role should not be 'stopped' before that .
>
> Maybe my expectations are wrong ?
>
> Best Regards,
> Strahil Nikolov
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20210402/177acdeb/attachment-0001.htm>