| Author |
Message
|
| mqsme |
 Posted: Mon Sep 16, 2013 10:30 am Post subject: Retry channel status and clusmgrs do not match |
 |
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
Hi,
I have two MQ servers joining in cluster. MQM_B used to joining cluster in MQM_A_OLD in old server and now joining cluster in MQM_A_NEW in new server. MQM_A_NEW is full repository and MQM_B is only partial.
In MQM_B, the channel status to MQM_A_NEW keeps retrying. I check the log in AMQERR01.log, it shows MQM_B keeps retrying to connect to MQM_A_OLD fail (because it is removed)
in MQM_B
7 : dis clusqmgr(*) channel deftype,conname
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(MQM_A) CHANNEL(to.MQM_A)
CLUSTER(RELTEST_MQCLUSTER) CONNAME(MQM_A_OLD(1420))
DEFTYPE(CLUSSDRB)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(MQM_B) CHANNEL(to.MQM_B)
CLUSTER(RELTEST_MQCLUSTER) CONNAME(MQM_B(1422))
DEFTYPE(CLUSRCVR)
I believe because the CONNAME still pointing to MQM_A_OLD. Can anyone tell how can I change it to MQM_A_NEW please? Thanks a lot |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Sep 16, 2013 10:44 am Post subject: Re: Retry channel status and clusmgrs do not match |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsme wrote: |
| Can anyone tell how can I change it to MQM_A_NEW please? |
How did you attempt to move the queue manager from one cluster to another? Did you actually try to move the queue manager using a procedure you invented, or did you add to MQM_A_NEW and remove from MQM_A_OLD as described in the documentation?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsme |
| Posted: Mon Sep 16, 2013 10:55 am Post subject: |
|
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
|
| Back to top |
|
|
| mqsme |
| Posted: Mon Sep 16, 2013 11:12 am Post subject: |
|
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
In MQM_B
11 : dis chstatus(*)
AMQ8417: Display Channel Status details.
CHANNEL(to.MQM_A) CHLTYPE(CLUSSDR)
CONNAME(MQM_A_OLD(1420)) CURRENT
RQMNAME( ) STATUS(RETRYING)
SUBSTATE( ) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
12 : dis chl('to.MQM_A') conname
AMQ8414: Display Channel details.
CHANNEL(to.MQM_A) CHLTYPE(CLUSSDR)
CONNAME(MQM_A_NEW(1420))
how it can be happen? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 16, 2013 11:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsme wrote: |
| how it can be happen? |
By "remove MQM from cluster" do you mean the ALTER CHANNEL command from the doc?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsme |
| Posted: Mon Sep 16, 2013 12:01 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
| Alter + STOP + Delete in step 5,6,7 |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 16, 2013 12:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsme wrote: |
| Alter + STOP + Delete in step 5,6,7 |
As 3 commands immediately one after the other? Did you allow the change to be propagated through the cluster? Have you refreshed the cluster (as indicated)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsme |
| Posted: Mon Sep 16, 2013 12:56 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
yes, around immediately. 30 seconds gap sth. How long should I wait to issue each command?
Don't remember whether refreshed or not. Now I issue REFRESH CLUSTER REPOS( YES), it prompts out along about cluster queue errors
AMQ9407: Cluster queue MQ1 is defined inconsistently.
EXPLANATION:
The definition of cluster queue MQ1 on the queue manager with
UUID MQM_A_2008-08-18_11.10.17 has different DEFPRTY, DEFPSIST and DEFBIND
values from the definition of the same cluster queue on the queue manager with
UUID MQM_B_2013-08-30_18.13.02. Both definitions now exist in the local
repository. All definitions of the same cluster queue should be identical. In
particular, problems arise if your applications rely on a queue default value
which is defined inconsistently to determine messaging behavior. This applies,
for example, if the applications open a cluster queue with option
MQOO_BIND_AS_Q_DEF. If different instances of the queue have different DEFBIND
values the behavior of the message transfer differs depending on which instance
of the queue is selected when it is opened. In general the instance selected
varies across opens.
ACTION:
For each inconsistency decide which of the values is the correct one. Alter the
definitions of cluster queue MQ1 |
|
| Back to top |
|
|
| mqsme |
| Posted: Mon Sep 16, 2013 1:06 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
wait.. after refresh, altough getting many warnings at AMQERROR01.LOG now i check the channel, it is running.
1 : dis chstatus(*)
AMQ8417: Display Channel Status details.
CHANNEL(to.MQM_A) CHLTYPE(CLUSSDR)
CONNAME(MQM_A_NEW_IP(1420)) CURRENT
RQMNAME(MQM_A) STATUS(RUNNING)
SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8417: Display Channel Status details.
CHANNEL(to.MQM_B) CHLTYPE(CLUSRCVR)
CONNAME(MQM_A_NEW_IP) CURRENT
RQMNAME(MQM_A) STATUS(RUNNING)
SUBSTATE(RECEIVE)
does it look good? In Queue manager Clusters section of MQ Explorer, I can see MQM_A as full repository, MQM_B as partial respository
shall I still solve the cluster queue conflict? Thanks.
Last edited by mqsme on Mon Sep 16, 2013 1:08 pm; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 16, 2013 1:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsme wrote: |
| shall I still solve the cluster queue conflict? |
Of course! Why do you need to ask? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 16, 2013 1:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsme wrote: |
| does it look good? In Queue manager Clusters section of MQ Explorer, I can see MQM_A as full repository, MQM_B as partial respository |
I'd be inclined to do a DIS CLUSQMGR(*) from the command line just to be sure.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsme |
| Posted: Mon Sep 16, 2013 1:45 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2013
Posts: 51
|
At MQM_B
4 : dis clusqmgr(*)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(MQM_A) CHANNEL(to.MQM_A)
CLUSTER(MQCLUSTER)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(MQM_B) CHANNEL(to.MQM_B)
CLUSTER(MQCLUSTER)
It looks like everything is fine, thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 17, 2013 4:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsme wrote: |
| It looks like everything is fine, thanks. |
Which is what the Explorer was saying, but I'm an old fashion, command prompt type of guy
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Sep 17, 2013 5:28 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
To add to Vitor's command line comment, it has been my experience that MQ Explorer may give you different and seemingly incorrect results when displaying cluster information.
You may have noticed that when you connect only to a Qmgr that is not a full repository from MQ Explorer, it will only display the names of the clusters and members of the full repository Qmgrs. I don't know why they chose not to display the contents of the PR which you can see using the command line, but that is how it works.
I suspect that when you see inconsistent results in MQ Explorer vs the command line, what you are seeing is fragmented information in the Full Repository Qmgrs (this is where the FRs did not get a complete set of cluster updates about objects).
When you have a cluster related issue, you must compare the definition in your PR to the definition in each FR (which you should only have two FRs). You may also need to compare the definition with the Qmgr that hosts the object in question. You cannot do these comparisons using MQ Explorer.
Finally, don't host application queues on the FR Qmgrs. Create a separate Qmgr (on the same machine if you don't have the equipment) to only be the FR(s). Once you have isolated FR Qmgrs, you should never have to issue any cluster commands at those. Don't issue REFRESH CLUSTER(BLA) REPOS(YES) at an FR (for cluster BLA). |
|
| Back to top |
|
|
|
|
