| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multi-instance QMGR start time |
« View previous topic :: View next topic » |
| Author |
Message
|
| gavze007 |
 Posted: Tue Oct 16, 2018 4:43 am Post subject: Multi-instance QMGR start time |
 |
|
Novice
Joined: 28 Mar 2018
Posts: 19
|
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 |
|
 |
| Vitor |
| Posted: Tue Oct 16, 2018 5:28 am Post subject: Re: Multi-instance QMGR start time |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| gavze007 |
| Posted: Tue Oct 16, 2018 11:28 pm Post subject: |
|
|
Novice
Joined: 28 Mar 2018
Posts: 19
|
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 |
|
|
| Vitor |
| Posted: Wed Oct 17, 2018 5:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
