| Author |
Message
|
| abytjose |
 Posted: Tue Apr 16, 2013 6:27 am Post subject: Steps for upgrading MQ v6.0.2.8 to MQ v7.5 on MSCS win2003 |
 |
|
Newbie
Joined: 15 Nov 2011
Posts: 5
|
Please correct/help me If I am wrong.
Suppose two nodes are in the MSCS cluster ie. node A and node B.
On node A
1) Shut down the queue manager, and check that there are no errors.
2) Make a full backup of the queue files and log files and store the backup in a safe place and also take saveqmgr backup of the queue manager.
3) Make sure that the shared disk on which the files currently reside is online on the cluster node to which to move the queue manager log and data files.
4) Stop the cluster service on the node being migrated.This step is necessary to clear the MSCS cache of any MQ dlls it has registered.
5) Stop the queue manager and MQ services from the node.
6) Issue the command haregtyp /u
7) Then Issue the command hamvmqm /m qmname /dd "C:\Program Files\IBM\WebSphere MQ\Qmgrs" /ld C:\Program Files\IBM\WebSphere MQ\log"
as data and logs files resides in E:\WebSphereMQ(shared drive)
(Will the above command automatically moves data and logs from E:\WebSphereMQ back to C:\Program Files\IBM\WebSphere MQ\Qmgrs? )
 start the queue manager and restore the queue manager backup and test the queue manager to ensure that it works.
9) As the files are available locally, upgrade the MQ to v7.5.
10) Issue the command haregtyp /r
11) Then issue the command hamvmqm /m qmname /dd "E:\WebSphereMQ" /ld E:\WebSphereMQ" to move data and log files to shared drive.
12) Then ask windows admin the node to MSCS cluster service on the node.
do we need to follow the same steps in node B as the node B is running in MQ v6.0.2.8?
What is the next step? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Apr 16, 2013 6:50 am Post subject: Re: Steps for upgrading MQ v6.0.2.8 to MQ v7.5 on MSCS win20 |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| abytjose wrote: |
7) Then Issue the command hamvmqm /m qmname /dd "C:\Program Files\IBM\WebSphere MQ\Qmgrs" /ld C:\Program Files\IBM\WebSphere MQ\log"
as data and logs files resides in E:\WebSphereMQ(shared drive)
(Will the above command automatically moves data and logs from E:\WebSphereMQ back to C:\Program Files\IBM\WebSphere MQ\Qmgrs? ) |
Yes, that's what it's designed to do - move queue manager files in/out of 'shared' storage locations...
| abytjose wrote: |
| 8 ) start the queue manager and restore the queue manager backup... |
Why, it's the same queue manager as it was before? Unless you intend deleting the data/log files when you uninstall the previous version...
| abytjose wrote: |
| ...do we need to follow the same steps in node B as the node B is running in MQ v6.0.2.8? |
You need to upgrade both nodes to the same software level, as stated in the Info Centre.
The WMQ V7.5 Info Centre has THIS to say about migrating from V6.0 to V7.5 for a four-node cluster but the principle is the same.
_________________
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 |
|
|
| abytjose |
| Posted: Tue Apr 16, 2013 7:21 am Post subject: |
|
|
Newbie
Joined: 15 Nov 2011
Posts: 5
|
Then we can conclude the steps for upgrade as below.
Suppose two nodes are in the MSCS cluster ie. node A and node B.
On node A
1) Shut down the queue manager, and check that there are no errors.
2) Make a full backup of the queue files and log files and store the backup in a safe place and also take saveqmgr backup of the queue manager.
3) Make sure that the shared disk on which the files currently reside is online on the cluster node to which to move the queue manager log and data files.
4) Ask windows admin to stop the cluster service on the node being migrated.This step is necessary to clear the MSCS cache of any MQ dlls it has registered.
5) Stop MQ services from on the node.
6) Issue the command haregtyp /u
7) Then Issue the command hamvmqm /m qmname /dd "C:\Program Files\IBM\WebSphere MQ\Qmgrs" /ld C:\Program Files\IBM\WebSphere MQ\log"
as data and logs files resides in E:\WebSphereMQ (shared drive)
(Will the above command automatically moves data and logs from E:\WebSphereMQ back to C:\Program Files\IBM\WebSphere MQ\Qmgrs? )
start the queue manager to ensure that it works.
9) As the files are available locally, upgrade the MQ to v7.5.
10) Issue the command haregtyp /r
11) Then issue the command hamvmqm /m qmname /dd "E:\WebSphereMQ" /ld E:\WebSphereMQ" to move data and log files to shared drive.
12) Then ask windows admin to start MSCS cluster service on the node.
13) Go to node B and repeat the steps from step 3) to step 12. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Apr 16, 2013 7:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If you're asking for someone to confirm what the Info Centre states (and which you have paraphrased) because you do not trust the Info Centre, then either raise a PMR with IBM to confirm and clarify or contract [insert preferred supplier here] to do it so that any blame for failure accrues to the individual doing the work.
_________________
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 |
|
|
| Vitor |
| Posted: Tue Apr 16, 2013 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abytjose wrote: |
| Then we can conclude the steps for upgrade as below. |
We may conclude what we wish. If you have concluded those are the steps then go in peace and perform them. Bear in mind that, even if we happened to conclude those are the steps, in the event of any issues your management are unlikely to be impressed by an explaination of "well I asked this group of random strangers on the Internet if these were the correct steps for the upgrade and they concluded they were".
We also cannot be certain that those steps are correct for your specific environment, that there are not other steps required for your environment (e.g. missing permissions), that you will not encounter issues in your environment (e.g. mismatched SID, MSCS issues, etc) or a myraid of other possible trip points.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abytjose |
| Posted: Wed Apr 17, 2013 1:35 am Post subject: |
|
|
Newbie
Joined: 15 Nov 2011
Posts: 5
|
Hi,
Thanks a lot for your updates.
I just tried to prepare a generalised steps for MQ upgrade on MSCS which might be useful in future for anybody. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 17, 2013 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abytjose wrote: |
| I just tried to prepare a generalised steps for MQ upgrade on MSCS which might be useful in future for anybody. |
It's a kind thought, but IBM already summarised them in the InfoCenter and they can be held accountable for the contents of that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
