| Author |
Message
|
| cra1gl1 |
 Posted: Tue Jul 17, 2018 7:04 am Post subject: Disaster Recovery available options |
 |
|
Apprentice
Joined: 25 Apr 2018
Posts: 30
|
Hi experts,
I've been trying to understand how DR can be achieved in MQ.
From what i gathered, there are the below 3 options available.
Back up the queue manager data: This needs the qmgr to be stopped, so may not be ideal for DR
Use a backup queue manager: This doesn't work for Circular logging
Back up the queue manager configuration only: This works for only mq configuration
So, for with circular logging, looks like only the 3rd option is available and it requires manual installation and creation of the qmgr on the DR site?
Is htere any other way to achieve MQ DR which doesn't require a manual MQ installation on the DR site?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jul 17, 2018 7:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Put the queue manager data on replicated disc (a high tech version of taking a backup). SAN replication software handles open files and your recovery point is as near to real time as the replication can manage (which is seriously YMMV given the number of factors that can affect it!)
I don't think there's a good way to avoid installing MQ at the DR site. You can of course put the binaries on SAN as well which would "install" on the DR site but that's not a "good" thing by any sane measure.
You can of course automatically install MQ at the DR site in the same way you should be automatically installing it on the main site.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| cra1gl1 |
| Posted: Tue Jul 17, 2018 8:22 am Post subject: |
|
|
Apprentice
Joined: 25 Apr 2018
Posts: 30
|
| Vitor wrote: |
| Put the queue manager data on replicated disc (a high tech version of taking a backup). SAN replication software handles open files and your recovery point is as near to real time as the replication can manage (which is seriously YMMV given the number of factors that can affect it!) |
so, this is basically same as backing up queue manager data without having to stop the qmgr?
And /var/mqm/qmgrs and /var/mqm/logs is hte only data that needs to be put on the replicated disc ? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 17, 2018 9:00 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
One of the MQ V9.0 releases has the facility to provide Disaster Recovery Replicated Data Queue Managers (DRRDQM).
There are restrictions, but potentially it's one way of achieving the DR you seek.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 17, 2018 9:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| cra1gl1 wrote: |
| so, this is basically same as backing up queue manager data without having to stop the qmgr? |
Replication creates a copy of the files. I think that's a definition of "backing up"
| cra1gl1 wrote: |
| And /var/mqm/qmgrs and /var/mqm/logs is hte only data that needs to be put on the replicated disc ? |
If you stopped the queue manager and took a backup, what directories would you backup?
Replicate those.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 17, 2018 9:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
One of the MQ V9.0 releases has the facility to provide Disaster Recovery Replicated Data Queue Managers (DRRDQM).
There are restrictions, but potentially it's one way of achieving the DR you seek. |
It's 9.0.4 and I don't think replicated queue managers are intended as a DR solution:
| Quote: |
| The nodes in an RDQM HA Group are likely to be closer to each other than a remote file server is so the network latency is likely to be lower and the bandwidth higher |
Running these over a geographically widespread domain is likely to be problematic. But you're right, it is a technologically viable alternative.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 17, 2018 9:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
One of the MQ V9.0 releases has the facility to provide Disaster Recovery Replicated Data Queue Managers (DRRDQM).
There are restrictions, but potentially it's one way of achieving the DR you seek. |
It's 9.0.4 and I don't think replicated queue managers are intended as a DR solution: |
I was thinking of 9.0.5, which does 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 17, 2018 10:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
| exerk wrote: |
One of the MQ V9.0 releases has the facility to provide Disaster Recovery Replicated Data Queue Managers (DRRDQM).
There are restrictions, but potentially it's one way of achieving the DR you seek. |
It's 9.0.4 and I don't think replicated queue managers are intended as a DR solution: |
I was thinking of 9.0.5, which does |
I am enlightened by new knowledge. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 17, 2018 10:15 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
| Vitor wrote: |
| exerk wrote: |
One of the MQ V9.0 releases has the facility to provide Disaster Recovery Replicated Data Queue Managers (DRRDQM).
There are restrictions, but potentially it's one way of achieving the DR you seek. |
It's 9.0.4 and I don't think replicated queue managers are intended as a DR solution: |
I was thinking of 9.0.5, which does |
I am enlightened by new knowledge. |
They keep adding the toys so fast it's sometimes difficult to keep up...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 17, 2018 11:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Vitor wrote: |
| exerk wrote: |
| Vitor wrote: |
| exerk wrote: |
One of the MQ V9.0 releases has the facility to provide Disaster Recovery Replicated Data Queue Managers (DRRDQM).
There are restrictions, but potentially it's one way of achieving the DR you seek. |
It's 9.0.4 and I don't think replicated queue managers are intended as a DR solution: |
I was thinking of 9.0.5, which does |
I am enlightened by new knowledge. |
Pay attention in class!
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 17, 2018 7:29 pm Post subject: Re: Disaster Recovery available options |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| cra1gl1 wrote: |
Is htere any other way to achieve MQ DR which doesn't require a manual MQ installation on the DR site?
|
If you can use virtual servers, replicate the entire virtual server at the storage layer.
At the DR site, the software and procedures that bring up the replicated copy of the server also assign it the DR personality, primarily changing the IP address. Otherwise it looks just like the Production server did.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 18, 2018 3:52 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
In a real DR, where the MQ queue manager host can't be easily recovered / restored and there is no cross-datacenter OS HA capability or synchronous disk replication, the best practise is to recreate the queue manager on a DR server using backup of object defs, and hand the local queues to the app in an EMPTY state.
Applications should not rely 100% on MQ as a data store. They should be able to reconcile / replay / ignore duplicate messages. In a business sense, MQ does not own the data that is stored in messages, so should not be accountable for its integrity in a business sense.
MQ admins attempting to reload or restore queued messages from prior to the DR can actually cause major issues for apps, as the apps will then process old (and possibly partial) streams of messages. Apps are going to have a hard enough time dealing with the DR, and would probably prefer not to have MQ throwing more fuel into the fire.
_________________
Glenn |
|
| Back to top |
|
|
|
|
