New post
Question
· Mar 10, 2023

ZSTOP - Type of Shutdown that occured

#High Availability #ObjectScript #System Administration #InterSystems IRIS

I am looking into creating a ZSTOP as you probably have seen from my previous posts, is there a way to capture the type of shutdown that occurred? So say if there was an unknown hardware failure (forced), vs a user shutdown? Mainly looking for user or system shutdown when we force another destination to become the primary in the mirror. So if a user shutdown the production to do.,... Task A, Task B etc..

 

Thanks

Scott 

Product version: IRIS 2022.1
$ZV: IRIS for UNIX (Red Hat Enterprise Linux 8 for x86-64) 2022.1 (Build 209U) Tue May 31 2022 12:13:24 EDT
Discussion (3)3
Log in or sign up to continue
Pietro Montorfano · Mar 15, 2023

Hi Scott,
not an expert for zstop, but what you are looking for cannot be developed with the zstop.

With an "iris force", hardware failure (hard power off, server fault,... anything that is not a "polite" shutdown) or other similar condition where iris simply is killed, no zstop is executed. You can only be aware of an unclean shutdown at the iris restart, but that's too late for what you are looking to do.

What you can do is to have an agent that monitors the iris instance (qlist, process, messages.log) and execute action when certain conditions are met.

Moreover i haven't found anything on the "shutdown" cause, it's just a shutdown inside iris i think

Pietro

1 0
Lorenzo Scalese · Mar 16, 2023

I agree with @Pietro Montorfano , due to the type of failure it's not possible to know the stop reason.  
Also, If it's an abnormal stop the execution of ZSTOP is not guaranteed.  

Depending on your target, maybe you can execute code on start (ZSTART routine) to clean something when the system has been stopped abnormally.  It could be identified by a trace in your application database or a scan of the messages.log

1 0
Vic Sun · Mar 16, 2023

I agree with Lorenzo and Pietro as well! Since I believe you're looking to run tasks/code that has to do with your mirror failing over, I suppose it might be worth taking a higher level look at the scenarios you are hoping to address. Probably most of the things you want to do can be put in your ZMIRROR so that when your new primary takes over it can do whatever miscellaneous non-IRIS failover tasks you want.

What procedures do you need to be concerned about in a clean failover via shutting down the instance (triggering ZSTOP) vs in an unclean failover for whatever reason, in which case you would only expect your ZMIRROR to run?

1 0