| Author |
Message
|
| Kurgan |
 Posted: Mon Aug 21, 2006 7:02 pm Post subject: Multiple instances of FP QMs in a cluster question |
 |
|
Newbie
Joined: 14 Aug 2006
Posts: 3
Location: Sydney Australia
|
First time poster - long time reader
I have had a situation were an AIX admin recreated a AIX LPAR on another AIX LPAR - WMQ included. On the original LPAR there lives a full repository queue manager (there is another repository with many partials). On the new LPAR, being a full copy of the original one, WMQ was started. This meant two repository queue managers with identical name & ID were running.
Luckily I got to shut the copy down before any issues arose. But my question is:
What would have been the potential impact of this situation if the copy queue manager started its cluster channels?
Gus |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Mon Aug 21, 2006 10:11 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
its a no-no. results are unpredicatable, worst case is that you end up with a non working mqseries cluster.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 22, 2006 12:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Queue managers must be unique within a cluster. It would have resulted in a very contact admin mess - I think the correct IBM-speak is "the results of this opperation are undefined", commonly translated as "We've no idea what's going to happen, but it's not going to be good"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Aug 22, 2006 12:28 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| Vitor wrote: |
Queue managers must be unique within a cluster. It would have resulted in a very contact admin mess - I think the correct IBM-speak is "the results of this opperation are undefined", commonly translated as "We've no idea what's going to happen, but it's not going to be good"
|
I had such a situation in one of my test environments  . Due to QMgrs are identified by the unique QMIDs, the situation is bad, but not hopeless. I could remove the second (accidently added) repository from the cluster, but it was a hard job  .
With several REFRESHes, RESETtings with ACTION(FORCEREMOVE), removing and recreating of cluster channels, changing cluster repositories - and all in specific orders - I could remove the second REPOS  .
But simplify your live and use unique QMgr names !!!
_________________
Regards
Hubert |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 22, 2006 2:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In situations like this, your best bet is to drop the cluster and rebuild it.
Also - NEVER bring up a DR environment on the same network as your production environment for testing purposes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Aug 22, 2006 6:03 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| jefflowrey wrote: |
| In situations like this, your best bet is to drop the cluster and rebuild it. |
Live is not always that easy - ask my customers .
| jefflowrey wrote: |
| Also - NEVER bring up a DR environment on the same network as your production environment for testing purposes. |
I agree absolutely.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 22, 2006 6:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| HubertKleinmanns wrote: |
| jefflowrey wrote: |
| In situations like this, your best bet is to drop the cluster and rebuild it. |
Live is not always that easy - ask my customers |
I agree. Sometimes the best way isn't the right way.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Kurgan |
| Posted: Tue Aug 22, 2006 10:47 pm Post subject: |
|
|
Newbie
Joined: 14 Aug 2006
Posts: 3
Location: Sydney Australia
|
Thank you for your responses. I have got enough to raise some eyebrows.
I will:
-Create a new QM (different name as well) on the new box
-Recreate/import all the local queue definitions
-Define new cluster channels for connecting to a different cluster & then join it
-Define new cluster queues that are similar to the real ones - pointing back to the new QM
Gus
_________________
Angus Sutherland
WMQ is Middleware, but not all Middleware is WMQ |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Aug 22, 2006 11:02 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
Kurgan,
you should always have two FR at any time. Put the FR on different machines, which are nearly all the time available. DO NOT start the second repository only in DR case. All full repositories must be connected together, so that they are able, to exchange their repository contents.
It does not matter, when a FR is not available for a while, but when you start it only in case of DR, the cluster definitions may be expired and you will have no (working) FR!
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
