ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportMulti-instance QMGR start time

Post new topicReply to topic
Multi-instance QMGR start time View previous topic :: View next topic
Author Message
gavze007
PostPosted: Tue Oct 16, 2018 4:43 am Post subject: Multi-instance QMGR start time Reply with quote

Novice

Joined: 28 Mar 2018
Posts: 18

Hi,

I've been doing some tests of running multi instance QMGR on MQ 9.0.3 on AWS, as an active-standby solution for our production environment.

I started the QMGR on two servers using the "-x" switch (strmqm -x QM1) and did some failover tests.

When the QMGR runs on the first server, I killed it and waited until it started on the server running the standby QMGR. I named them HOST-1 (active) and HOST-2 (standby) on the logs.
I killed it at 12:31:17 and immediately errors were logged, and it started on the standby instance at 12:32:49 (92 seconds).

Are there any configuration parameters I can change that will cause the failover to happen quickly?

Thanks

These are the logs:

10/16/2018 12:31:17 PM - Process(26313.2) User(root) Program(runmqlsr)
Host(HOST-1) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:31:17.736Z)

AMQ6209: An unexpected asynchronous signal (1 : SIGHUP) has been received and
ignored.

EXPLANATION:
Process 1 received an unexpected asynchronous signal and ignored it. This has
not caused an error but the source of the signal should be determined as it is
likely that the signal has been generated externally to IBM MQ.
ACTION:
Determine the source of the signal and prevent it from re-occurring.
----- amqxerrx.c : 773 --------------------------------------------------------
10/16/2018 12:31:17 PM - Process(26313.2) User(root) Program(runmqlsr)
Host(HOST-1) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:31:17.737Z)

AMQ6209: An unexpected asynchronous signal (15 : SIGTERM) has been received and
ignored.

EXPLANATION:
Process 1 received an unexpected asynchronous signal and ignored it. This has
not caused an error but the source of the signal should be determined as it is
likely that the signal has been generated externally to IBM MQ.
ACTION:
Determine the source of the signal and prevent it from re-occurring.
----- amqxfdcx.c : 849 --------------------------------------------------------
10/16/2018 12:31:17 PM - Process(26313.2) User(root) Program(runmqlsr)
Host(HOST-1) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:31:17.737Z)

AMQ6183: An internal IBM MQ error has occurred.

EXPLANATION:
An error has been detected, and the IBM MQ error recording routine has been
called. The failing process is process 26313.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier and to save any generated output files. Use either the MQ Support
site: http://www.ibm.com/software/integration/wmq/support/, or IBM Support
Assistant (ISA): http://www.ibm.com/software/support/isa/, to see whether a
solution is already available. If you are unable to find a match, contact your
IBM support center. Do not discard these files until the problem has been
resolved.
----- amqxfdcx.c : 896 --------------------------------------------------------
10/16/2018 12:31:17 PM - Process(26283.2) User(root) Program(runmqchi)
Host(HOST-1) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:31:17.735Z)

AMQ6209: An unexpected asynchronous signal (1 : SIGHUP) has been received and
ignored.

EXPLANATION:
Process 1 received an unexpected asynchronous signal and ignored it. This has
not caused an error but the source of the signal should be determined as it is
likely that the signal has been generated externally to IBM MQ.
ACTION:
Determine the source of the signal and prevent it from re-occurring.
----- amqxerrx.c : 773 --------------------------------------------------------
10/16/2018 12:31:17 PM - Process(26283.2) User(root) Program(runmqchi)
Host(HOST-1) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:31:17.736Z)

AMQ6209: An unexpected asynchronous signal (15 : SIGTERM) has been received and
ignored.

EXPLANATION:
Process 1 received an unexpected asynchronous signal and ignored it. This has
not caused an error but the source of the signal should be determined as it is
likely that the signal has been generated externally to IBM MQ.
ACTION:
Determine the source of the signal and prevent it from re-occurring.
----- amqxfdcx.c : 849 --------------------------------------------------------
10/16/2018 12:31:17 PM - Process(26283.2) User(root) Program(runmqchi)
Host(HOST-1) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:31:17.736Z)

AMQ6183: An internal IBM MQ error has occurred.

EXPLANATION:
An error has been detected, and the IBM MQ error recording routine has been
called. The failing process is process 26283.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier and to save any generated output files. Use either the MQ Support
site: http://www.ibm.com/software/integration/wmq/support/, or IBM Support
Assistant (ISA): http://www.ibm.com/software/support/isa/, to see whether a
solution is already available. If you are unable to find a match, contact your
IBM support center. Do not discard these files until the problem has been
resolved.
----- amqxfdcx.c : 896 --------------------------------------------------------
10/16/2018 12:32:49 PM - Process(1950.1) User(mqm) Program(amqzxma0)
Host(HOST-2) Installation(Installation1)
VRMF(9.0.3.0) QMgr(QM1)
Time(2018-10-16T12:32:49.241Z)

AMQ8352: IBM MQ queue manager 'QM1' becoming the active instance.

EXPLANATION:
The standby instance of queue manager instance 'QM1' is becoming the active
instance.
ACTION:
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Oct 16, 2018 5:28 am Post subject: Re: Multi-instance QMGR start time Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25310
Location: Ohio, USA

gavze007 wrote:
Are there any configuration parameters I can change that will cause the failover to happen quickly?


The standby queue manager will kick in when the lock the active queue manager has on the disc is released. You need to speak to your contact admin people.

Don't make it too short or the queue managers will switch over every time the network hiccups.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
gavze007
PostPosted: Tue Oct 16, 2018 11:28 pm Post subject: Reply with quote

Novice

Joined: 28 Mar 2018
Posts: 18

I am the admin.
The disk lock was released the moment the server was rebooted - so I don't understand why it took it 90 seconds to failover to the standby server.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Oct 17, 2018 5:07 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25310
Location: Ohio, USA

gavze007 wrote:
The disk lock was released the moment the server was rebooted


Really?

gavze007 wrote:
I killed it at 12:31:17 and immediately errors were logged


So are you saying the "it" in this instance was the OS itself? Is it your assertion that issued a restart command to the OS, at which point the queue manager started to issue messages and it dropped the disc lock? At that exact moment, even though it was logging messages as it went down in flames into the bottom of the server, it dropped the disc lock to signal to it's standby?

What kind of lease parameters to you have on that disc?

Given that this is the case (and my disbelief still needs to lose a little weight before I'll be able to suspend it), you then assert that the standby queue manager (on a server where the clock is exactly synchronized with the first) did not issue any messages indicating an attempt to become active until 12:32:49?

Do I have the scenario straight?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportMulti-instance QMGR start time
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.