|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Recovery Scenarios |
« View previous topic :: View next topic » |
Author |
Message
|
hopsala |
Posted: Sun Jul 18, 2010 11:21 am Post subject: Recovery Scenarios |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
Hey guys, long time no see. Been traveling abroad. I'm back, for now
Anyway, I've been thinking up different crash and recovery scenarios for a client, and read all I could find but still couldn't find answers to a few nagging questions (these were especially helpful: Tool to save CM domain configuration & Is it worth backing up the Config Manager?)So here goes:
Let's say my CM crashes, and I have a day old backup. In the time passed between the backup and the crash, I've deployed one flow and deleted another. Now I recover BERNARD and... what? I imagine I simply won't see the extra deployed flow, but what of the deleted flow? I can bring things back into sync by re-deploying the new flow, but how do I resynch information about the deleted flow?
In general, what I'm trying get at up is that restoring the CM from a backup can create quite confusing inconsistencies - moved, deleted, created MFs, EGs, maps, JARs, not to mention collectives and pubsub info (and maybe something else?) - which could potentially be impossible to untangle. So other than a very clear manual log of deploys and version control, is there any other way to make sure a recovered CM can be resynched?
A second scenario: Say my broker crashes, and I recover from a day old backup. Now the same thing happens. The CM thinks the broker runs a flow it doesn't, and doesn't run a flow it does. What's the best way to resynch? I'm pretty sure this is equivalent to the previous scenario, but I may be missing something.
Lastly, in both situations I could adopt the broker, but this only syncs MFs and EGs, not maps, JARs, MRMs and adapter files. How do I resynch these entites? is redeploying the only option?
And yea, I know I can move to the wonderous omnipotent V7. I tried to explain to the client it will take him less time to make the upgrade than plan for recovery, but no such luck.  |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Jul 18, 2010 11:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
v6.1 will automatically resynch the broker and the configmgr on a regular interval, roughly an hour by default.
et voila.
In *general*, the best recovery strategy is to put everything under change control, and do all deployments from specific scripts.
Then you can just rerun scripts after recovery. |
|
Back to top |
|
 |
hopsala |
Posted: Sun Jul 18, 2010 9:18 pm Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
mqjeff wrote: |
v6.1 will automatically resynch the broker and the configmgr on a regular interval, roughly an hour by default. |
Well that's good to know, I don't remember seeing this in the info center or any of the posts I've read. I'll send a doc feedback unless you can direct me to the proper page. Does this process resynch everything? MFs, EGs, maps, JARs, etc?
And more importantly, is there a way to explicitly initiate a resynch or control the time span?
mqjeff wrote: |
In *general*, the best recovery strategy is to put everything under change control, and do all deployments from specific scripts.
Then you can just rerun scripts after recovery. |
Agreed. Assume an average client: No scripts, no documentation of deployments. Hence the problem. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Jul 19, 2010 1:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
There is at least documentation on BIP1587 and it's ilk. I'd have thought there would be a mention somewhere specifically otherwise, but not exactly finding it.
I think this was "snuck in" at FP2. Perhaps someone who knows for sure will be along in a bit to comment. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Jul 19, 2010 3:29 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
http://www-01.ibm.com/support/docview.wss?uid=swg21420337
Quote: |
This technote covers the following questions:
1. What is the "Automatic Synchronization" feature of WebSphere Message Broker 6.1?
2. Why are there large amounts of processing occurring once every hour?
3. Why are some of my Execution Groups renamed to "Discovered EG" followed by numbers?
4. Can this synchronization between the configuration manager and broker be configured?
|
_________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
hopsala |
Posted: Tue Jul 20, 2010 10:07 pm Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
Great! That's exactly what I was looking for
It doesn't specify, however, if everything is synchronized. I guess I'll just experiment and see what happens. If it works as designed, then the best recovery procedure is to restore from a CM backup and resyncing using the CMP "Discover components from runtime" command. I'll send a doc feedback about this feature, it's important enough to get it's own page in the recovery section of the lit.
Thanks for the help  |
|
Back to top |
|
 |
Amitha |
Posted: Wed Jul 21, 2010 10:21 am Post subject: |
|
|
 Voyager
Joined: 20 Nov 2009 Posts: 80 Location: Newyork
|
Quote: |
In *general*, the best recovery strategy is to put everything under change control, and do all deployments from specific scripts.
Then you can just rerun scripts after recovery. |
Does this mean that we need to still deploy bar files after recovery, even though config manager is synchronized up to date?
Even if we need to sync config manager, can we just use CMP "Discover Components from Runtime " and sync the config manager without redeploying the bar file. |
|
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
|
|
|
|