|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ Cluster - Replace a full repository Queue Manager |
« View previous topic :: View next topic » |
Author |
Message
|
OzgurAydin |
Posted: Tue Oct 13, 2015 12:57 am Post subject: MQ Cluster - Replace a full repository Queue Manager |
|
|
 Apprentice
Joined: 08 Sep 2008 Posts: 27
|
Hi,
We have this situation. One of our old queue managers running on 7.0.1.5 is set to be replaced with a new version 7.5 queue manager due to some log files being used during normal operation and resulting in outage of the queue manager applications.
How are we going to replace the queue manager which holds the full repository for the cluster ? There are some queue managers added to the cluster using cluster sender and receiver channels to the one we are planning to remove ? How are we going to change these connections ? Or do we have to ???
In total there are 5 queue managers in the cluster now. During the work we will be adding two new queue managers to the cluster. Which will make the total number of 7. Can somebody give us a best practice on how to add and remove the relevant queue managers ?
Thank you. |
|
Back to top |
|
 |
mo_lightapps |
Posted: Thu Oct 22, 2015 12:15 am Post subject: |
|
|
Novice
Joined: 12 Oct 2015 Posts: 18
|
Sounds like you need to rebuild the cluster. Sorry, dont think there is any other predictable and clean way to do it.
Rough sequence of recovery:
isolate all of the partial repositories from the full repository queue manager by shutting down clusddr and clusrcvr channels
isolate all client applications by shutting down svrconn channels
clear all queue managers SYSTEM.CLUSTER.REPOSITORY.QUEUE
resume cluster operations by enabling inbound channels to full repository, step by step introduce the partial repositories
Check the cluster status along the way and the depth of the cluster repository queue
Use some mq put tools to verify status _________________ LightApps - Creators of Lighthouse software. Modern web based management of messaging systems IBM MQ and Solace - queue browsing, automated configuration deployment and monitoring.
www.lightapps.com.au |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 22, 2015 4:34 am Post subject: Re: MQ Cluster - Replace a full repository Queue Manager |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
OzgurAydin wrote: |
Hi,
We have this situation. One of our old queue managers running on 7.0.1.5 is set to be replaced with a new version 7.5 queue manager due to some log files being used during normal operation and resulting in outage of the queue manager applications.
How are we going to replace the queue manager which holds the full repository for the cluster ? There are some queue managers added to the cluster using cluster sender and receiver channels to the one we are planning to remove ? How are we going to change these connections ? Or do we have to ???
In total there are 5 queue managers in the cluster now. During the work we will be adding two new queue managers to the cluster. Which will make the total number of 7. Can somebody give us a best practice on how to add and remove the relevant queue managers ?
Thank you. |
If you are running in a correctly configured cluster this should be a no brainer...
First stop one of the FR's and make a backup of it. Then upgrade to 7.5.
Start it @ 7.5 et voila.... Repeat...
Now if you are going to fully replace the FR queue manager, you would have to:
- Create another full repository, preferably at 7.5 (having briefly 3 repositories there.
- switch all manually defined cluster senders from the PRs to the old repository to the new repository
- demote the old repository to a PR
- Remove the PR from the cluster following procedure (see cluster manual
Hope it helps  _________________ MQ & Broker admin |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu Oct 22, 2015 12:11 pm Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
Remember, every FR in a cluster must have an explicit cluster sender channel to each of the other FRs in the cluster. If you have three FRs, then each FR should have two explicit cluster senders to the other FRs.
Why? Because an FR that receives a cluster update will only forward that update to the other FRs to which it has an explicit cluster sender channel. Don't keep it at three FRs, but demote one. You want at least two and no more than two FRs.
I agree with fjb_saper's suggestion.
If you are going between like systems (AIX to AIX), you probably could "copy" the Qmgr's data and logs to the new system and migrate at that moment. CLUSRCVRs need to be updated with the new host name. |
|
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
|
|
|
|