| Author |
Message
|
| vsathyan |
 Posted: Wed Jun 24, 2015 3:58 am Post subject: Cluster Repository Migration |
 |
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Is it necessary to remove the 'REPOS' attribute of a queue manager and make it ' ' before bringing it down for a version upgrade?
Say, we have repository running on 7.5.0.2 and I want to upgrade the version to 7.5.0.5, should I make it as a partial repository before bringing it down?
Also, what would be advisable to migrate the repositories - both the repositories in a short time say a day or two, or upgrade one repository today and do the next one after a week or two?
Thank you.
_________________
Custom WebSphere MQ Tools Development C# & Java
WebSphere MQ Solution Architect Since 2011
WebSphere MQ Admin Since 2004 |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Jun 24, 2015 4:08 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
It's not a version upgrade you're doing, you're applying maintenance. Take down one FR at a time, ensuring there is at least one FR available within the cluster. Whether to stage the maintenance across your FRs is a question of your confidence in the stability of your cluster(s).
_________________
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 |
|
|
| vsathyan |
| Posted: Wed Jun 24, 2015 4:10 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Hi Exerk,
I'm sure about taking down 1 FR at a time. But the question is - should it be made a partial repository before bringing it down?
Thanks,
_________________
Custom WebSphere MQ Tools Development C# & Java
WebSphere MQ Solution Architect Since 2011
WebSphere MQ Admin Since 2004 |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 24, 2015 4:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| vsathyan wrote: |
I'm sure about taking down 1 FR at a time. But the question is - should it be made a partial repository before bringing it down?
|
My question is, why do you think that is necessary?
_________________
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 |
|
|
| vsathyan |
| Posted: Wed Jun 24, 2015 4:18 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
If I say -
"tell all the Partial Repos that I am not a FR again and don't send me anything..."
is that not a valid point ?
_________________
Custom WebSphere MQ Tools Development C# & Java
WebSphere MQ Solution Architect Since 2011
WebSphere MQ Admin Since 2004 |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 24, 2015 4:41 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You have two (hopefully) FRs and if you demote one to a PR you'll have to promote a PR to an FR, swing over all necessary connections to it, and then do it all over again in reverse - and of course your FRs should always be the ones at the latest version/maintenance level.
So, again, I ask: what is it that concerns you?
_________________
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 |
|
|
| vsathyan |
| Posted: Wed Jun 24, 2015 5:08 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Sorry if my question is not clear.
I know about method 1 and have done it earlier, but got information about method 2 while talking to one of my peer. Hence wanted to take the best approach and advise.
Steps to apply maintenance fix pack on a Linux server running Cluster Full Repository
Method 1
1. Suspend the FR queue manager in cluster
2. Bring down the FR
3. Backup the FR data and logs directory
4. Apply the Fix Pack / Maintenance
5. Bring up the FR
6. Resume the FR queue manager in cluster
or
Method 2
1. Make the FR queue manager as a PR
2. Bring down the FR
3. Backup the FR data and logs directory
4. Apply the Fix Pack / Maintenance
5. Bring up the FR
6. Make the PR back as FR
Which one the above two methods should I follow?
Or if there is any other better process advisable, please let me know.
Thanks in advance.
_________________
Custom WebSphere MQ Tools Development C# & Java
WebSphere MQ Solution Architect Since 2011
WebSphere MQ Admin Since 2004 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 24, 2015 5:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The big difference with method 2 is that it allows you to use refresh cluster(cluster) repos(yes) on your partial.
Don't know of what value that would be if your cluster is well behaved... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jun 24, 2015 5:04 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
An advantage of having at least 2 FR is that you can take one down for maintenance and the MQ cluster will still be fully functional. You don't need to demote a FR for maintenance. Shut down the qmgr, apply maintenance, start it up.
If all cluster queues and qmgrs are fully advertised to all PR qmgrs in the MQ cluster, so that all apps can run successfully, and you are not introducing new clustered objects, you can actually have no FR qmgrs running, and the PR qmgrs will still be able to resolve and deliver messages! (provided there are no app objects on the FRs that are clustered -- this is best practise)
_________________
Glenn |
|
| Back to top |
|
|
|
|
