| Author |
Message
|
| Sam Uppu |
 Posted: Wed Mar 06, 2013 3:10 pm Post subject: MB migration question from 6.1 to 8 |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi,
We are planning to migrate the brokers from current 6.1 to v8. Current brokers (6.1) are running on Linux machines and new MB v8 will be installed on new Linux servers. We will create new broker QMgrs(with different name) and broker name just like the current v6.1.
Once the broker is created on v8, I dont want to miss any of the broker and EG settings compared to the old one. I want to make sure the broker settings, EGs and their settings similar to the old broker.
Question:
Is there anyway to backup the v6.1 broker and EGs/ settings and replay on v8 broker?. Please let me know.
Once the broker and EGs are created just like the v6.1 broker, the development team will provide the new bars with v8 bar files to deploy.
Thanks. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Mar 06, 2013 11:25 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You could perhaps use mqsimigratecomponents to upgrade your current broker and then mqsibackupbroker and mqsirestorebroker to move it.
You could also list the settings with mqsireportproperties to capture configurable services and most other values. I think the biggest hassle is extracting the dbparms value that have been set.
IBM don't really document if you can lift bits of the registry like the DSN directory and drop it into the new registry. It's something that could do with some product enhancement, especially to extract values in the command format needed to re-issue the commands. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Mar 07, 2013 1:44 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
If I have interpreted correcly from between the lines the preferred way for these situation is to have decent change management processes by which all the changes to the environment are recorded in the way that they can be replayed easily.
--
Marko |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 07, 2013 1:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Having the ability to list what's in there, in command format, is always useful and indeed there are several MQ tools for doing just that for queue definitions and authority records.
Replaying several years worth of recorded command history in the same order as before would be one fairly painful way of doing it, and of course you also lose the GUI option.
For production brokers such an inflexible approach might be OK, but people have to move their development environments as well sometimes. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Mar 07, 2013 2:34 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
I agree with the idea having a tool (like saveqmgr for WMQ) also for the broker with which you could export current settings of the runtime objects in the portable, editable and replayable form.
I created RFE to have this tool available at the future.
--
Marko |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 20, 2013 2:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
How is it possible that only 3 people voted for this RFE... 
I voted for it, I assume marko voted for it. Only one other person finds value in being able to export EVERY setting from a Broker to be used to build a new Broker?
No, mqsirestorebroker does not fulfill this need.
http://pic.dhe.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/bn43010_.htm
| Quote: |
| You can restore a broker only on a computer that has an identical configuration; the operating system must be at the same level, and the broker and queue manager names must be identical. |
That last part is what limits the usefulness of mqsibackupbroker and mqsirestorebroker. If I'm building a new system to scale out horizontally, my Broker and QM names must be different, so an mqsibackupbroker file is useless to me. Or maybe my new QA Broker is just perfect, and its time to build the Production version of it. Being able to use mqsirestorebroker from the QA backup to create a new Production version Broker (so new name) that is exactly like QA would be the bee's knees.
Maybe the RFE is really to just remove the restriction of having to have the same Broker Name and QM name? Or maybe add some optional flags for the mqsirestorebroker command where you can specify the new Broker Name and the new QM name if you want, otherwise it defaults to the names of the Broker/QM that got backed up?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Dec 21, 2013 12:41 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Perhaps this RFE was a little more descriptive
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=40438
That is Planned for a future release
Yay!
 
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Dec 21, 2013 6:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Alrighty then, I voted for that one too. I added this comment to it:
| Quote: |
| When IBM implements a solution for this, please make it possible to use the export/mqsireportbroker from one Broker as an import/mqsichangebroker for another new Broker that has a different name. This will be very useful for cloning existing Brokers when going from QA to PROD, or when scaling horizontally with additional Brokers in an MQ cluster. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
