| Author |
Message
|
| Trainee |
 Posted: Tue Mar 27, 2007 11:44 am Post subject: Suspend the queuemanager from cluster while doing migration |
 |
|
Centurion
Joined: 27 Oct 2006
Posts: 124
|
Hi
We are planning to migrate the WMQ 5.3 to 6 on AIX .
Queue Managers are in cluster.
Other guys in my team are saying that we need to suspend the queue managers from cluster and after migratioin &restart the queue manager we can resume cluster.
My openion is not to touch the cluster as migration don't need that.Touching the cluster without need will be risk(may lead to cluster problems)
When We applied the patches we didn't suspend the queue manager from the cluster on which we are applying patch
Any one can suggest.
Thank you
Trainee |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 27, 2007 11:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What are you basing your opinion on?
What reasons did the "others on your team" give for wanting to suspend the queue manager?
What does the Clusters manual have to say on the subject?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbburson |
| Posted: Tue Mar 27, 2007 12:32 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
For what it's worth, our plan here for upgrading 5.3 to 6 on AIX does not include suspending the queue managers from the WMQ clusters. We have 7 clusters with 6 to 12 queue managers per cluster. One has been completely upgraded with no problems. The others are scheduled through the next couple of months.
We do make sure to upgrade the full repositories first followed by the partials. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Tue Mar 27, 2007 10:21 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
Hi
Its good and safer if you suspend the cluster before doing migration.
There is chance of getting locked, if you dont suspend the cluster.
this will result in a bad situation.
Think of it,
Thanks and Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Mar 27, 2007 10:33 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| jefflowrey wrote: |
What does the Clusters manual have to say on the subject? |
quite clear on the subject 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Trainee |
| Posted: Wed Mar 28, 2007 3:48 am Post subject: |
|
|
Centurion
Joined: 27 Oct 2006
Posts: 124
|
Which one I have to follow bbburson or Gaya3
Thanks
Trainee |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 28, 2007 3:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Trainee wrote: |
Which one I have to follow bbburson or Gaya3
|
Now that's what we call one of those decision things.... 
I'd start with answering the questions asked by jefflowrey - how did you form the opinion you didn't need to suspend? Is that opinion based on creditable sources? Do you stand by it?
Secondly, query the "others on your team". Did they find other, equally credible but conflicting sources or do they just think it sounds safer?
Thirdly, check the documentation. The Clusters manual will aid you in minimising the impact of suspending a queue manager, the Migration guide will provide valuable pointers for the process.
My personal view - set up a test cluster and migrate that. You can try suspending and not suspending and see what works best in your environment - no-one in here (with all respect to my fellow posters) can know exactly what you should do because none of us are fully aware of all your circumstances, risk aversion, politics, etc, etc. Our opinions and advice are no more (but no less) than that.
My 2 cents - suspension is unnecessary. But see above re: opinions!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Mar 28, 2007 4:18 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 28, 2007 10:01 am Post subject: |
|
|
Guest
|
Back to the original post:
As a best practice (common sense?), you should ensure that the qmgr you are about to upgrade is quiesced (not doing any real work). The upgrade process is going to upgrade mq things in the mq path.
In the case of a cluster qmgr, real work can come from any other qmgr in the cluster.
The Queue Manager Clusters manual gives you the cookbook procedure to follow to remove a queue manager from the cluster.
The discussion here (including the one from Hursley) is 'should' vs. 'must.' If you have write rights to the path, you can upgrade. Should you? What can go wrong if you do?
The same issue applies equally as well to non-mq applications. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Mar 29, 2007 1:55 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| Trainee wrote: |
Which one I have to follow bbburson or Gaya3
Thanks
Trainee |
Suspending a QMgr in a cluster means, tell the others, I would not like to get any messages for a while. So other QMgrs in the cluster will take over the tasks.
Resuming a QMgr in a cluster means, tell the others, I am able, to take over some work again.
When you resume a QMgr and wait a while (until all application queues became empty), then you are quite sure, that no messages are stucking somewhere on your QMgr during upgrade.
I am not quite sure, what happens, when a cluster queue is hosted only by the suspended QMgr. I think, the message to this Q will be delivered anyway (but it does not really matter, whether the messages stuck on the application Q or in the XmitQ of the sending QMgr )
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
