| Author |
Message
|
| PeterPotkay |
 Posted: Mon Sep 24, 2007 5:41 pm Post subject: mqsimigratecomponents |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The info center does say the command can be run with the -c switch while the broker is running if you want to check to see if the migration will work.
| Quote: |
The migration check can be run against a running component. This does not impact the component, except for imposing a slight performance penalty.
|
Works fine. Says I'm ready to migrate.
What about when its time to run the actual migration? Do I stop the Broker but leave DB2 runnning? Or can/should the command be run on a running broker that has had incoming traffic routed away from it?
The Broker is currently WBIMB 5.0.4. Migrating to WMB 6.0.0.5 on a Windows 2003 server in a MSCS cluster.
When I migrated the Config Manager (on a separate server) I did stop it before migrating it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| mqmatt |
| Posted: Tue Sep 25, 2007 3:57 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Correct; stop the broker but leave DB2 and MQ running. Then migrate. Then restart the broker.
Cheers
-Matt |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 25, 2007 7:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Thanks Matt. That's what I suspected.
When the migrate command runs on the broker it doesn't make any changes to the flows, right? If it did the next time we deployed a flow it would overwrite the migrate command's changes.
So if any flows need to be changed to work with 6.0, like replacing the MQGET Node Support pack from 2.1/5.0 with the new "real" version, or any other ESQL type changes, they need to be made in the Toolkit ahead of time and then as soon as I run the migrate command on the broker we then deploy all the changed flows?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqmatt |
| Posted: Wed Sep 26, 2007 2:01 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Yes, that's right- the migrate utility does very little (if any) tinkering with the message flows themselves. Instead, it concentrates on getting the internal database structures, queues etc. correct.
It's up to you to redeploy any existing flows with updated and changed capability.
There is a supportpac you might like to look at, which analyzes your ESQL for any potential migration issues: http://www.ibm.com/support/docview.wss?uid=swg24012060
There is also a technote that the L3 support team produced, which describes the migration issues that have been reported through the service channel: http://www.ibm.com/support/docview.wss?rs=849&uid=swg21255570 (most of which are quite obscure though, so nothing to worry about).
Cheers
-Matt |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 27, 2007 6:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hey Matt, that Support Pack say:
| Quote: |
PROBABLE USES
Assisting customers in migration from v2.1 to v6.0 who are hit by a change in behaviour of implicit and explicit casts from decimal to character.
|
We are going from 5.0 to 6.0. Will it apply?
I've run into some problems with the migration. On Node 1 when I start up the broker it now just stops and restarts every minute trying to access some unknown DB instead of the DB its been using for the past 3 years.
| Code: |
Event Type: Error
Event Source: WebSphere Broker v6005
Event Category: None
Event ID: 2053
Date: 9/27/2007
Time: 9:56:09 AM
User: N/A
Computer: MyServerName
Description:
( HIGMQIL1 ) The broker made an unsuccessful attempt to access its database 'MessageBroker' with userid ''.
The broker's database could not be accessed using the userid and password supplied.
Ensure that the database is running and that the userid and password are correct.
|
I opened a PMR to find out why its now looking for the DB called 'MessageBroker' instead of its real DB.
Another snafu was that I tried moving the broker over to Node 2 and started it up. It did, but as Version 5.0! The documentation makes no mention of having to run mqsimigratecomponents on all nodes in the hardware cluster. I figured that if I ran the command on the node where the DB2 DB was online those changes would take hold and be respected by the other nodes as I moved the group around.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Sep 27, 2007 7:57 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Hi Peter,
| PeterPotkay wrote: |
| We are going from 5.0 to 6.0. Will it apply? |
Maybe - but most of the tightening up of ESQL syntax that led to such problems happened between v2.1 and v5, so you should already be OK here.
| PeterPotkay wrote: |
| I've run into some problems with the migration. |
Not heard of either of these ones. Let us know the resolution when it comes.  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 19, 2007 1:11 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This was a fun one:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/WebSphereMQIntegrator/2/BrokerName
This Registry Key is associated with a Message Broker.
When MSCS manages a resource, it watches over the registry keys associated with that resource. Anytime that resource goes offline, MSCS "hardens" the latest registry values for those keys and uses them upon the next startup of that resource, either on the same node or another node. Any changes made to those keys while the resource is offline are overwritten with the hardened values the next time it comes up. This is good because it insure MSCS brings up the resource looking the same way it did the last time it was running. So if you are going to do something that requires changes to the registry key you have to do it with the resource online. An MQSeries Queue Manager has the same issue, and I imagine other software resources do too.
But the WMB Migration requires the Broker to be offline to migrate, creating a catch-22. You need it online so the registry changes stick, but you need it offline to migrate. The only solution is to delete the Broker resource in MSCS prior to the migration. Once the migration is completed, you recreate the Broker resource. At resource creation time you can tell MSCS what registry key to associate with this resource (its the Registry Replication parm for the Broker resource in MSCS), and you will now tell MSCS to watch and save the new Version 6 ready key.
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/MQSeriesBroker/BrokerName/ImagePath.
This key dictates what's displayed in the Services Window for the IBM MQSeries Broker Service for the "path to executable". Basically this tells the server what version of WMB or WB-IMB to start the broker up as. The mqsimigratecomponents command does handle this on the primary node when you are running the migration. But it does not do it on any of the other nodes. And if you try and run the mqsimigratecomponents on the other nodes it sees the broker is already at 6.0 and doesn't do anything. We manually modified that key on the secondary node to match the primary node. I suppose another option is to add this other key as well into the Registry Replication parm window for the Broker resource in MSCS. That way as the broker is moved from node to node this parm is kept in sync.
Basically what it boils down to is that the mqsimigratecomponents command is completely unaware of Microsoft Hardware Cluster.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
