| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Practice for MQ upgrade |
« View previous topic :: View next topic » |
| Author |
Message
|
| ftdmnt1600 |
 Posted: Fri Jul 20, 2018 12:25 am Post subject: Practice for MQ upgrade |
 |
|
Novice
Joined: 20 Jul 2018
Posts: 11
|
I am working on a project of upgrading MQ 8 to MQ9.
- QM A is existing MQ8, in use, connecting to remote QM X
- I created new v9 QM, also named A, as it's supposed to replace the old A
Problem is, old QM A will exist for months, as there are a few projects running on it, and I need to test the MQ objects ( queues / channels ) on new QM A
Question is, what's the best practice for this case? new QM has same name with old QM |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Sun Jul 22, 2018 3:52 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
You are already deviating from best practice onto a path of pain and suffering. Never create a qmgr with the same name as an existing qmgr. Use a new name, use it for shake-out testing, and migrate the apps to use it.
If the same name must be retained, totally isolate the new qmgr instance, and do a big-bang cutover (shutdown and disable the old instance, then start up / start channels on the new instance).
_________________
Glenn |
|
| Back to top |
|
|
| ftdmnt1600 |
| Posted: Mon Jul 23, 2018 4:21 am Post subject: |
|
|
Novice
Joined: 20 Jul 2018
Posts: 11
|
| gbaddeley wrote: |
You are already deviating from best practice onto a path of pain and suffering. Never create a qmgr with the same name as an existing qmgr. Use a new name, use it for shake-out testing, and migrate the apps to use it.
If the same name must be retained, totally isolate the new qmgr instance, and do a big-bang cutover (shutdown and disable the old instance, then start up / start channels on the new instance). |
Many thanks for the reply.
Application is using the existing MQ server, in parallel I am building the new server, ideally we should remain the MQ objects the same ( QM name, channel, etc) , which brings minimal change to application.
Problem is, existing MQ server A connects to remote MQ server B, new built MQ server A should connects to same remote MQ server, then we have trouble on the channel name and transit queue etc ... |
|
| Back to top |
|
|
| rammer |
| Posted: Mon Jul 23, 2018 4:47 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| You have to create new channels etc no other way around it... In which case maybe best to follow best practice and do not add another QMGR with the same name. Either way new channels etc are needed... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 23, 2018 7:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| rammer wrote: |
| You have to create new channels etc no other way around it... In which case maybe best to follow best practice and do not add another QMGR with the same name. Either way new channels etc are needed... |
New channels? What alternative is there for a new qmgr?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 23, 2018 4:06 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| ftdmnt1600 wrote: |
Many thanks for the reply.
Application is using the existing MQ server, in parallel I am building the new server, ideally we should remain the MQ objects the same ( QM name, channel, etc) , which brings minimal change to application.
Problem is, existing MQ server A connects to remote MQ server B, new built MQ server A should connects to same remote MQ server, then we have trouble on the channel name and transit queue etc ... |
Minimal change to application or trouble with channel names etc is not an excuse for compromising MQ best practice. You need to take time to design the best method for migration that will be supportable into the future. Regarding app changes, you should tell them exactly what needs to be changed, and ensure that they do it, and test.
_________________
Glenn |
|
| Back to top |
|
|
| ftdmnt1600 |
| Posted: Tue Jul 24, 2018 9:05 pm Post subject: |
|
|
Novice
Joined: 20 Jul 2018
Posts: 11
|
| gbaddeley wrote: |
| ftdmnt1600 wrote: |
Many thanks for the reply.
Application is using the existing MQ server, in parallel I am building the new server, ideally we should remain the MQ objects the same ( QM name, channel, etc) , which brings minimal change to application.
Problem is, existing MQ server A connects to remote MQ server B, new built MQ server A should connects to same remote MQ server, then we have trouble on the channel name and transit queue etc ... |
Minimal change to application or trouble with channel names etc is not an excuse for compromising MQ best practice. You need to take time to design the best method for migration that will be supportable into the future. Regarding app changes, you should tell them exactly what needs to be changed, and ensure that they do it, and test. |
thanks I will go through this with team |
|
| 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
|
|
|
|
