|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
mqsibackupbroker subtleties |
« View previous topic :: View next topic » |
Author |
Message
|
hopsala |
Posted: Sun Jul 03, 2011 4:43 am Post subject: mqsibackupbroker subtleties |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
In http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/bn43020_.htm it says
Quote: |
You can run this command for a broker that is active. However, you must not take a backup while the broker is processing configuration changes and deployments; the backup file created might contain incomplete information. If the file contains partial records, you cannot use it to restore the broker at a later time. |
I find this disconcerting. First off, if I want to script this, I am unaware of a command that checks whether config changes are in progress (but I'll happily stand corrected), and even if there was, there is always the chance that right running such a command after someone will issue a deployment, right when I'm backing things up.
What's really worrying is that apparently mqsibackupbroker will finish without errors even if there are config changes in progress, and you'll have a defunct backup without ever knowing.
I'm not I'm not the first to come across this. Has anyone come up with a reasonable solution? |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Jul 03, 2011 5:20 am Post subject: Re: mqsibackupbroker subtleties |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
hopsala wrote: |
In http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/bn43020_.htm it says
Quote: |
You can run this command for a broker that is active. However, you must not take a backup while the broker is processing configuration changes and deployments; the backup file created might contain incomplete information. If the file contains partial records, you cannot use it to restore the broker at a later time. |
I find this disconcerting. First off, if I want to script this, I am unaware of a command that checks whether config changes are in progress (but I'll happily stand corrected), and even if there was, there is always the chance that right running such a command after someone will issue a deployment, right when I'm backing things up.
What's really worrying is that apparently mqsibackupbroker will finish without errors even if there are config changes in progress, and you'll have a defunct backup without ever knowing.
I'm not I'm not the first to come across this. Has anyone come up with a reasonable solution? |
I am a little bit surprised. You sound like you have no control over the environment....
Forgetting about DEV/QA let's look more strictly at production.
I would certainly hope that your deployments are scheduled and you would precisely know when a backup had a chance of being compromised.
Now let's look at DEV/QA...
You mean to say that you cannot control the environment in such a way that you can ensure there will be no deployment while you run a backup?
I understand that developers may expect the environment to be up 24/7 however an announced maintenance interval goes a long way about securing you the time needed. If anything else fails you can stop the channel used for deployment.
You do use a specific channel for deployment don't you?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
smdavies99 |
Posted: Sun Jul 03, 2011 5:56 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
You could take some defensive steps to do something which I personally think is just not required in practice.
Things like shutting down the WMQ Listener used for deployments, stopping the channel used for deployments AND telling people not to issue any mqsichange commands on the broker.
OR
Even doing something as simple as stopping the broker.
Ok, the last and most obvious choice might not be possible in your production environment.
As has been said, do your backups when you know that there are not going to be ANY config changes going on. If you are in control of the broker environment and you should be if you are in a position to do this sort of operation. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
hopsala |
Posted: Sun Jul 03, 2011 6:35 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
All that you say above is right. Really, I completely agree. The thing is that I have on my hands a rather odd requirement from a client over which I have only limited control. Besides, it seems to me that it's good practice to hope for the best but script for the worst - The script itself should be as error-proof as possible; relying on human policies is second-best, although of course it is often unavoidable and justified. So I thought this would be an interesting conundrum to chew on, even if it is mostly theoretical..
Oh, and although I haven't seen this happen in V7, in V6 you could get a config change stuck in limbo for days or more (until you unstuck it, basically), and if this can happen in V7, you could end up with a whole set of backup files that don't work at all. In general I find it suspect that a command ends OK even if it's not OK, and it makes me wonder what other fault conditions the command may ignore.
But anyway, I do have a requirement on my hands, which, regardless if I'm able to dissuade my client from implementing or not, I should first consider. What I'm looking for is a way to backup my broker, while running, during busy uptime hours, without assuming that no one's not deploying something accidentally (as often happens during malfunctions, where everyone's doing everything once). If it's impossible, fine. But I'd like to make sure.
And last but not least, I think at least this bit is a valid question - how do you know when a config change is in progress? (if you haven't done it yourself, otherwise of course it shows in the toolkit) |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Jul 03, 2011 5:24 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Toolkit is fine, but the WMBExplorer is better there. Click on the broker and see the status messages scroll across the right part of the screen...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
hopsala |
Posted: Wed Jul 13, 2011 1:15 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
fjb_saper wrote: |
Toolkit is fine, but the WMBExplorer is better there. Click on the broker and see the status messages scroll across the right part of the screen... |
Right, I forgot about that. Thanks. This means it's programmable via CMP. But I'm not sure you can see deployments made by someone else. I'll check and see.
hopsala wrote: |
Oh, and although I haven't seen this happen in V7, in V6 you could get a config change stuck in limbo for days or more (until you unstuck it, basically), and if this can happen in V7, you could end up with a whole set of backup files that don't work at all. In general I find it suspect that a command ends OK even if it's not OK, and it makes me wonder what other fault conditions the command may ignore. |
Does anyone know if config messages can get 'stuck' in this way in V7? |
|
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
|
|
|
|