| Author |
Message
|
| Boomn4x4 |
 Posted: Wed Apr 25, 2012 7:18 am Post subject: Backing up QMGR with non-persistent messages |
 |
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
Is there any need to keep a continuous backup of MQ logs if none of the messages are persistent?
I'm currently working on putting a setup where a queue manager is backed up by having an identical queue manager on a second piece of hardware started for replay (strmqm -r $QMGR) to be used for system recovery. My intent is that if the primary system becomes available, the secondary system can be promoted and the queue manager will resume relaying messages. There will be no persistent messages in the chain.
I'm reading through the documentation, I think I under stand the process of linear logging and the process of advancing the logs to take incremental backups... and it appears to me that it is only necessary to do this if you have persistent messages in the chain. Since, in my case, there will only be non-persistent messages, there is no need to be keeping incrimental backups via ADVANCELOGS. As I am understanding, all I need to do is take a one time snap shot of /var/mqm/qmgrs/MYQMGR and keep it archived. If the primary fails, I can overlay that snap shot on the backup, activate the backup (strmqm -a MYQMGR) and start it, and I will have a fully functional queue manager as it was on the primary system.
Am I incorrect about any of this? Is there anything I'm missing? |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Apr 25, 2012 8:14 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Non-persistent messages do not survive an uncontrolled queue manager shut-down, e.g. power failure, but non-persistent messages delivered as NPMSPEED normal may survive a normal shut-down; therefore, your snap-shots may be useless to you. As far as I am aware, using a stand-by queue manager for a non-persistent-message queue manager is not valid.
_________________
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 |
|
|
| Boomn4x4 |
| Posted: Wed Apr 25, 2012 8:39 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| If I'm understanding correctly, if I don't have persistent messages, there is no reason to have a standby message queue? That, if I have a system failure, I simply recreate/configure a new queue manager? |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 25, 2012 8:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Your Disaster Recovery/Business Continuity solution needs to meet requirement. On the information you've given, if you're using all non-persistent messaging, it suggests to me that your requirement would be met by having a 'clone' queue manager waiting ready.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Apr 25, 2012 8:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You might want a standby queue manager if you have issues or concerns with things like qmid ids in an MQ Cluster or with significant effort to resolve channels that now are talking to a 'new' queue manager. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 25, 2012 2:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If you have only non-persistent messages, then there are no messages logged. If you/your apps don't care if messages are are summarily discarded at qmgr restart, then a new qmgr with re-created object definitions should work fine for you.
One of my clients uses mq for transporting telemetry data, and isn't concerned with message (data) loss. All messages are non-persistent.
_________________
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 |
|
|
| fjb_saper |
| Posted: Wed Apr 25, 2012 7:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
bad assumption from the op.
Agreed that if there are no persistent messages there will be no messages to replay.
However the standby qmgr still needs the logs, if only to get the object definitions that may happen in the primary and have them replicated to the DR qgmr.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 26, 2012 12:05 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| ...However the standby qmgr still needs the logs, if only to get the object definitions that may happen in the primary and have them replicated to the DR qgmr... |
A lot of effort when MS03 would suffice.
_________________
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 |
|
|
| Boomn4x4 |
| Posted: Thu Apr 26, 2012 3:40 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| fjb_saper wrote: |
bad assumption from the op.
Agreed that if there are no persistent messages there will be no messages to replay.
However the standby qmgr still needs the logs, if only to get the object definitions that may happen in the primary and have them replicated to the DR qgmr.
|
What is the significance of restoring a queue manager's object definitions from the log files as opposed to recreating the objects from scratch using the same script that was used to create the original QMGR? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2012 4:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Boomn4x4 wrote: |
| What is the significance of restoring a queue manager's object definitions from the log files as opposed to recreating the objects from scratch using the same script that was used to create the original QMGR? |
Speed & automation.
The question of if it's faster and more automated than running a script is specific to your indiviidual situation.
I also underline the comment of my most worthy associate a few posts back. If a queue manager participates in a cluster, if you recreate it using the original scripts used to create the original queue manager with the same name as the original queue manager, the cluster will not think it's the original queue manager but a new queue manager that confusingly has the same name as another queue manager in the cluster.
This makes bad things start to happen.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
