| Author |
Message
|
| smeunier |
 Posted: Tue Feb 05, 2013 12:23 pm Post subject: Recomendation/Thoughts |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
We have the standard two Full repository cluster setup, with about a dozen Partial Qmgrs in the cluster.
One of the Full Repository servers are going to be decommissioned and a new server will be brought online, which will replace the Full repository on the decommission server. When the new server comes online, the DNS which hold references to the old server will be modified to point to the new server.
Since the the new servers QMGR which will become the new second Full repository will have the SAME QMGR as the previous QMGR, I'm concerned about possible residual cluster references to the OLD QMID.
My thought was, to take the existing QMGR and demote it to a PR, and then remove the QMGR from the cluster via standard protocol(Chapter 10 on the book pretty much). However, I'm not sure, that ALL references to the old QMID will be removed to all the PR's and when I bring the new QMGR with the same name into the cluster (different QMID) there could be delivery problems(or lack there of. I have seen what happens when two QMGRS with the same same get introduced to a cluster).
Would the easiest thing to do, to insure clean up, be to just issue a RESET with FORCEREMOVE? Also, the PR's CLUSSDR/CLUSRCVR channels with reference to the old FR should not need an action to be performed should they as the DNS change, will resolve to the old address as before? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Feb 05, 2013 12:45 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Does it really need to be a new QMID?
Can you backup the queue manager and restore it, per steps in the documentation, rather than deleting it and creating it anew? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 05, 2013 1:02 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do your FRs also host applications? (One school of thought is to have FRs that do nothing else other than host object definitions for the cluster.)
If your FR does not host apps, then you can create a new qmgr with any name to become the FR.
Do your apps MQCONN to the FR qmgr by name?
_________________
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 |
|
|
| smeunier |
| Posted: Tue Feb 05, 2013 1:03 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Jeff,
No it does not need to be a new QMGR-ID. In fact wouldn't this make life simpler?! Weh you say back-up/restore are you talking about a complete backup of the QMGR data ...log file, file system? Also it is going from MQ Version 6.0.28 to Version 7.0.1.5. Wouldn't that be like restoring to a down level? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 05, 2013 1:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smeunier wrote: |
| Wouldn't that be like restoring to a down level? |
So why not back it up and restore it on the new server as you describe above then upgrade to 7.0.1.5?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 05, 2013 3:16 pm Post subject: Re: Recomendation/Thoughts |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 05, 2013 3:33 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The cluster object definitions that reside in the former FR will stale out in 61 days, and be discarded from the repository.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Feb 05, 2013 3:51 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
Do your FRs also host applications? (One school of thought is to have FRs that do nothing else other than host object definitions for the cluster.)
If your FR does not host apps, then you can create a new qmgr with any name to become the FR.
Do your apps MQCONN to the FR qmgr by name? |
These are important questions. Depending on the answers this can be a lot simpler or a more complex activity.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smeunier |
| Posted: Wed Feb 06, 2013 6:47 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Code: |
| Do your FRs also host applications? (One school of thought is to have FRs that do nothing else other than host object definitions for the cluster.) |
Yes, this FR hosts application, which use bindings connections, there are also MQCONN connections being made by QMGR from client connects. There are to many legacy dependencies to change course at this time. The QMGR is also a mix of clustered usage as well as non-clustered with many channel connections. Moving to clustering is an ongoing challenge(long story).
| Code: |
| There is a page entitled "Moving a full repository to another queue manager" at http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/qc11660_.htm |
Yes, my current strategy is based on this.
I will investigate the backup further with the unix admins. V7 is already installed on the to-be server. I'm not sure they would want to downlevel then apply upgrades. |
|
| Back to top |
|
|
| smeunier |
| Posted: Wed Feb 06, 2013 10:56 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Just one final question on this. By suspending the FR's (Both need to be suspended during this work, as both servers are coming down for global infrastructure changes), will the changes I make to remove one FR be propagated to the other FR if it is suspended. It is clear that by suspending a QMGR from the cluster, it will not allow messages to be sent to that QMGR, but will repository messages continue to be exchanged?
In other words, are only data message halted, or are repository command messages halted as well?
Thanks in advance. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 06, 2013 11:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If the servers that host both FRs are to be shut down, apps that connect to PRs can be satisfied by PRs repository will continue to function.
Why don't you create a new non-app FR qmgr, and let it assume FR duties for PRs?
_________________
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 |
|
|
|
|
