| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Backup QM |
« View previous topic :: View next topic » |
| Author |
Message
|
| John89011 |
 Posted: Wed Sep 29, 2010 1:48 am Post subject: Backup QM |
 |
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
Hi,
I am considering creating backup queue managers and all the steps are clear as per Info Center. My only question is how will it behave in a cluster setup environment? Let's say I want to create a backup QM for one of my FR QM, FR QM fails and now backup QM with the same name and a different QM ID comes into play.
Thanks!!
Solaris 10 MQ v7+ |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Wed Sep 29, 2010 3:01 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
if i understand correctly you are talking about a cold standby queuemanager that replaces a failing queuemanager within an mqseries cluster ?!?
different qmid means different queuemanager in terms of mq cluster. all the other queuemanagers within the cluster know the "old" qmgr, not the "new" one. things may fail or may not be found unless the "new" queuemanager joins the cluster. in case of a FR, you have some things to consider, like the full connection to the other FRs, the non-up-to-date reposirory and so on.
dont know what else. just a few quick guessess....... maybe its better to go with different queuemanagernames, because also the qmid is different.
why dont you backup the original system and keep the restore available? in that case it is the "same" queuemanager, "just" the repository is old.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 29, 2010 4:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I believe that John89011 is talking about this.
And I'm not sure it will actually have a different QMID... ?
It's worth an experiment, I suppose. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Sep 29, 2010 5:54 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
no experience so far with that ......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| John89011 |
| Posted: Wed Sep 29, 2010 9:42 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Mr Butcher wrote: |
if i understand correctly you are talking about a cold standby queuemanager that replaces a failing queuemanager within an mqseries cluster ?!?
different qmid means different queuemanager in terms of mq cluster. all the other queuemanagers within the cluster know the "old" qmgr, not the "new" one. things may fail or may not be found unless the "new" queuemanager joins the cluster. in case of a FR, you have some things to consider, like the full connection to the other FRs, the non-up-to-date reposirory and so on.
dont know what else. just a few quick guessess....... maybe its better to go with different queuemanagernames, because also the qmid is different.
why dont you backup the original system and keep the restore available? in that case it is the "same" queuemanager, "just" the repository is old. |
Butcher, yes sorry I was not more specific.. it's bringing on a cold stanby queue manager... Info center states to create a standby queue manager with the same name. That's all great but what if that queue manager is in a cluster? In clustering 101, you should never create a queue manager with the same name as a queue manager that's already part of a cluster. I guess like mqjeff said, it's worth an experiment. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 29, 2010 11:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Consider IBMs statement regarding duplicate qmgr names in a cluster as a warning about concurrently running qmgrs. It is not an absolute that you must never, never, ...
(The owners manual that came with my car warns me about shifting into park while the car is in motion. However, Click and Clack suggest exactly that if you can't stop the car with brakes, parking brakes, the ignition turned off, ...)
In both cases, there are consequences.
If you are talking about cold failover or DR implementations, then you will not have duplicate qmgr names in a cluster.
| Quote: |
| And I'm not sure it will actually have a different QMID... ? |
Qmgr name and qmid are different, in that qmid contains the qmgr name and qmgr creation date/time-stamp information. It is highly unlikely that there would be a duplicate qmid.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Sep 29, 2010 11:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Consider IBMs statement regarding duplicate qmgr names in a cluster as a warning about concurrently running qmgrs. It is not an absolute that you must never, never, ... |
Yes, yes it is. It will not actually cause any queue managers to fail, but it will absolutely positively make all of your cluster traffic go higgeldy-piggeldy in very short order.
| bruce2359 wrote: |
| If you are talking about cold failover or DR implementations, then you will not have duplicate qmgr names in a cluster. |
Again, we're talking about something very specific, called a "backup queue manager". This is neither a cold failover or a DR implementation.
| bruce2359 wrote: |
| Quote: |
| And I'm not sure it will actually have a different QMID... ? |
Qmgr name and qmid are different, in that qmid contains the qmgr name and qmgr creation date/time-stamp information. It is highly unlikely that there would be a duplicate qmid. |
It's highly unlikely that two independently created QMIDS will be duplicated, yes.
That's again not what's being discussed. What's being discussed is something that is akin to restoring an entire server's file system from backup tape, but specific to MQ. The fact that the files in the qmgr directory are overwritten by the backup files is exactly what makes me suspect that the QMID will *not* be a new one. |
|
| 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
|
|
|
|
