| Author |
Message
|
| Sam Uppu |
 Posted: Mon Feb 22, 2010 5:36 pm Post subject: Moving a queue manager to a DR site |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We are planning to replicate the queue manager in DR site(site: LA) from our original site(site: NY).
Wondering whether we can copy the MQ file systems from NY and place it on the DR server LA(MQ already installed) and start the queue manager will work?.
or else do we need to copy the objects(saveqmgr) from site NY and run it on the DR queue manager and replace the log directory under LA queue manger with NY qmgr's log directory.
which one is the optimum way of doing?.
would appreciate your help on this.
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 22, 2010 5:51 pm Post subject: Re: Moving a queue manager to a DR site |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Wondering whether we can copy the MQ file systems from NY and place it on the DR server LA(MQ already installed) and start the queue manager will work?. |
If it's exactly the same WMQ on each site, and you want exactly the same queue manager, and there's no chance the queue managers will ever run at the same time, and the queue manager isn't in a cluster then yes you can.
If you have WMQv7 you can use the new features to do this for you.
You'll need to have some means of swapping the network over for DR or some means of editing the queue manager after copy so the channels work for the new location.
| Sam Uppu wrote: |
| or else do we need to copy the objects(saveqmgr) from site NY and run it on the DR queue manager and replace the log directory under LA queue manger with NY qmgr's log directory. |
If you can't use the method above (because of a cluster) this too works. Even if you can, you might find this easier as the changes to channels are more straightforward as text.
| Sam Uppu wrote: |
| which one is the optimum way of doing?. |
The one that fits your individual needs and circumstances best.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 22, 2010 9:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you use the built-in DR/recovery features remember that you need to periodically ship the logs over to the DR qmgr and start it with the "update from logs parm". You will have to do this one last time before starting it.
The easiest would then be to use linear logs as it would also capture qmgr changes (you should not have to run saveqmgr and update the DR).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 23, 2010 12:55 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
If you use the built-in DR/recovery features remember that you need to periodically ship the logs over to the DR qmgr and start it with the "update from logs parm". You will have to do this one last time before starting it.
The easiest would then be to use linear logs as it would also capture qmgr changes (you should not have to run saveqmgr and update the DR). |
The "backup queue manager" facility you mention only works for a queue manager with Linear Logs. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 23, 2010 1:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Presumably you want to recover messages to the current time?
But is this a valid DR scenario? If you lost your primary site, you can't get to the file system. You can get to an offsite backup if you have one.
This is the problem with MQ multi-instance QM as well. Only one copy of the data is maintained. It can provide failover but not DR recovery.
I think it's time for MQ to have a replication feature whereby all (persistent) messages (creation and deletion of) can be automatically sent to another QM (even one with the same QM name) to synchronise.
It might be done with log shipping, but I don't know of any product that supports MQ log shipping (and besides we use circular logs). |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 23, 2010 1:47 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| zpat wrote: |
I think it's time for MQ to have a replication feature whereby all (persistent) messages (creation and deletion of) can be automatically sent to another QM (even one with the same QM name) to synchronise.
It might be done with log shipping, but I don't know of any product that supports MQ log shipping (and besides we use circular logs). |
The "Backup queue manager" feature in MQ does this. Yes there is a fair amount of scripting to be added to make a complete solution, and indeed it only works for linear logs. It is also one-shot: there is no second failover of the queue manager.
On the additional scripting, this is a bit of extra work, but the backup strategy of different sites can vary so much that a set of scripts would only "fit" the needs of a small minority of sites.
(BTW, Just wondering, is anyone reading this using a Backup queue manager? Any experiences to share?)
On linear vs. circular logging, I don't think a comparable DR solution to Backup queue manager would be feasible for circular logs, just because of the essence of what circular logs are.
Lastly..
Tell your IBM account rep about your needs..  |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 23, 2010 2:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Something like Mimix for MQ (which is an i-series only product).
Ironic that the "out of favour" i-series has this capability(albeit with a 3rd party product) and the others don't.
By replication - I mean near real-time continuous updating, not a one-off recovery process. |
|
| Back to top |
|
|
| bjr149 |
| Posted: Wed Aug 04, 2010 4:56 am Post subject: |
|
|
Novice
Joined: 03 Mar 2010
Posts: 22
|
I was told that we cant use Mimix because our queue managers are not named the same on the production and dr site. This doesn't make sense to me because according to the IBM queue manager document "Guidelines for creating queue managers" you never name 2 queue managers the same on 1 network. Is this true?
Currently prod is RX1 and DR is RX2. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 04, 2010 5:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bjr149 wrote: |
| I was told that we cant use Mimix because our queue managers are not named the same on the production and dr site. This doesn't make sense to me because according to the IBM queue manager document "Guidelines for creating queue managers" you never name 2 queue managers the same on 1 network. Is this true? |
I don't believe it's true that you have your production queue manager and your DR queue manager on 1 network. Typically a DR site is a geographically remote location that spends much of it's time switched off.
It's certainly true that you should never name 2 queue managers the same on your network. But if you have an HA setup you could have "2" queue managers of the same name; one is the failover copy of the other. Likewise a DR copy of a queue manager has the same name as the real one because it was built to be an identical copy to be used in the case of disaster, when in all likehood it will be the only surviving queue manager of that name!
So if you've chosen not to follow this convention and have 2 queue managers called RX1 & RX2 which are the "same" then yes you can't do this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bjr149 |
| Posted: Wed Aug 04, 2010 5:11 am Post subject: |
|
|
Novice
Joined: 03 Mar 2010
Posts: 22
|
Let me change my post. The 2nd site is more of a failover site, not a dr site. Both servers are on the same network this is why they weren't named the same QM.
Both of these QM's are used in the local fashion on the 400 instance on each server. Can you somehow alias the RX2 or something to get around this?
If I can't use Mimix, which sucks, what are some other options that may fix my issue? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 04, 2010 5:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This would be better on your other thread, as you're not talking about DR as this thread is.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bjr149 |
| Posted: Wed Aug 04, 2010 8:20 am Post subject: |
|
|
Novice
Joined: 03 Mar 2010
Posts: 22
|
Vitor you mentioned
| Quote: |
| "It's certainly true that you should never name 2 queue managers the same on your network." |
Is there a place that shows this issues that could arise from doing this? We currently have a system that has queue managers named the same. This was before we knew anything about MQ and were told by some consultants that we shouldn't do this.
You also mentioned:
| Quote: |
| "But if you have an HA setup you could have "2" queue managers of the same name; one is the failover copy of the other." |
Is this assuming the failover server QM is not up? Im assuming for Mimix that the failover server would need to be up. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 04, 2010 8:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bjr149 wrote: |
Vitor you mentioned
| Quote: |
| "It's certainly true that you should never name 2 queue managers the same on your network." |
Is there a place that shows this issues that could arise from doing this? |
Look up "name resolution" in any of the documentation. Identically named queue managers mean you can't (or shouldn't) rely on MQ to route messages and have to hard code everything. Assuming you can. 2 identically named queue managers in a cluster will effectively destroy it.
| bjr149 wrote: |
| We currently have a system that has queue managers named the same. This was before we knew anything about MQ and were told by some consultants that we shouldn't do this. |
And you didn't believe them, even though you were paying for the expertise? Presumably you'll value this free advice even less..... 
| bjr149 wrote: |
| Im assuming for Mimix that the failover server would need to be up. |
Don't know, never used Mimix but why assume? Why not look in the documentation which (presumably) comes with it?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bjr149 |
| Posted: Wed Aug 04, 2010 10:54 am Post subject: |
|
|
Novice
Joined: 03 Mar 2010
Posts: 22
|
We do pass in the Q Manager in our code. I don't think we ever rely on MQ to "figure out" where to send the message. I'll have to look through the code.
| Quote: |
| And you didn't believe them, even though you were paying for the expertise? Presumably you'll value this free advice even less..... |
The first implementation wasn't with the consultants that is why I said that. On the current implementation we did not use the same. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 04, 2010 12:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bjr149 wrote: |
| We do pass in the Q Manager in our code. I don't think we ever rely on MQ to "figure out" where to send the message. |
So like I said you can't rely on WMQ to route the messages and are doing it yourselves. Nice wheel you've re-invented.
If the queue manager names are the same how does your application differentiate between them?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
