| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Automatic MQ switchover |
« View previous topic :: View next topic » |
| Author |
Message
|
| ramires |
 Posted: Thu Apr 28, 2011 1:45 pm Post subject: |
 |
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
You can specify multiple entries for CONNAME with MQ v7:
"You can provide multiple machine names to configure multiple connections with the same properties. The connections are tried in the order they are specified in the connection list until a connection is successfully established. If no connection is successful, the channel starts retry processing. "
I did not try this, not sure how this works with sequence numbers...
_________________
Obrigado / Thanks you |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Apr 28, 2011 1:57 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| ramires wrote: |
| You can specify multiple entries for CONNAME with MQ v7: |
The implication being those multiple entries relate to an MI queue manager...
| ramires wrote: |
| I did not try this, not sure how this works with sequence numbers... |
See above - it'll be the same queue manager and the same channel, with the 'same' sequence numbers..
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 28, 2011 2:01 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| exerk wrote: |
| shashivarungupta wrote: |
Inactive status :
The channel has ended processing normally or the channel has never started. Then why for Inactive ? |
Because INACTIVE is a 'normal' state and the OP wants to identify abnormal states  |
A healthy channel starting up does not go from Inactive (or Stopped), directly to Running. There are intermediate states. When things are fine, those states exist for a very small window of time, but if your script happens to catch it at just that instance......All of the sudden the simple little script needs to get more complicated. |
My point was that shashivarungupta did not seem to understand that INACTIVE was a state that the OP does not consider a 'failed' state. The states between inactive and running (provided the channel successfully reaches a running state) I would consider to also be 'normal' states.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| ramires |
| Posted: Thu Apr 28, 2011 2:11 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
no, they don't need to be MI queue managers, according the webcast: "Ask the Experts Replay: WebSphere MQ Failover on Distributed Platforms".
But in order to do this, each remote queue manager has to have a qmgr alias defined because it can receive messages not originaly destinated to it
_________________
Obrigado / Thanks you |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 28, 2011 2:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Channel states have been discussed many times here.
It is important to remember that RUNNING only indicates that
a) the channel is currently transmitting messages; or
b) the channel believes that when next it tries to transmit messages, it will be able to do so.
Given b) above, RUNNING is no guarantee that the channel is healthy and ready to transmit messages. The next attempt may fail.
The only channel state that explicitly and reliably indicates that the channel cannot transmit messages is STOPPED.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Apr 28, 2011 10:05 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| PeterPotkay wrote: |
| exerk wrote: |
| shashivarungupta wrote: |
Inactive status :
The channel has ended processing normally or the channel has never started. Then why for Inactive ? |
Because INACTIVE is a 'normal' state and the OP wants to identify abnormal states |
A healthy channel starting up does not go from Inactive (or Stopped), directly to Running. There are intermediate states. When things are fine, those states exist for a very small window of time, but if your script happens to catch it at just that instance......All of the sudden the simple little script needs to get more complicated. |
My point was that shashivarungupta did not seem to understand that INACTIVE was a state that the OP does not consider a 'failed' state. The states between inactive and running (provided the channel successfully reaches a running state) I would consider to also be 'normal' states. |
Again I can see a politician in you. 
If I was confused, PeterPotkay wouldn't have quoted yours point.
Or
Again re-read the statement from OP : there is 'or' NOT 'and' . Which clearly shows about two diff. conditions (failure / successful)
| vinay_s_s wrote: |
| If there is a change in status and if the status is not 'running' or 'inactive' |
And I agree with recent posts from PeterPotkay ! 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Apr 29, 2011 1:38 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| Gerd-in-ZA wrote: |
Is there some "halfway official" writeup that explains the difference between HA (high availability) and DR (disaster recovery)? For an HA solution we have a number of automatic solutions (from HACMP and the like to MI QMs or even shared queues on z/OS). For DR - long distance and not completely lossless (no shared server infrastructure) - we have a number of suggested "patterns" but no fully reliable fully automatic solution. This may change over time - it has already improved dramatically over my younger years.
I suspect the OP here has asked for a DR solution asking HA questions and reaping a few HA answers with a bit of "wise-old-head-shaking" why he didn't know all of this in the first place.
Best practice for a disaster management scenario is to have prepared manually a number of scripts that can be invoked semi-automatically in order to ensure that the failover - which will be somewhat lossy and potentially very expensive to revert - takes place completely under control of humans that can decide to abort and revert if they determine that the disaster case has not been reached yet.
Best practice for an HA scenario is automatic failover with as little visibility to the clients as possible, all based on the one key ingredient: reliable automatic detection of the primary's failure.
Best practice overall: To let HA take its course and take remedial action on the failed components in order to restore the inherent redundancy of the HA solution and then to progress to the DR plans once it is determined that the HA infrastructure is too far gone (both instances) to expect to go back to it in the near future. The time limits for decisions should be clearly defined and communicated well ahead of time, procedures should be practiced regularly. Post mortem analysis needs to be performed after such exercises and procedures and parameters need to be adjusted accordingly where needed.
We should be writing a redbook about this if we haven't yet. |
I think confusion between HA and DR is very common. This post is excellent, Gerd-in-ZA. Thank you for your contribution.
 |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
