Author |
Message
|
PeterPotkay |
Posted: Thu Dec 04, 2008 3:27 pm Post subject: Is it worth backing up the Config Manager? |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
WMB 6.1.0.3
The mqsibackupconfigmgr command lets you back up a CM's repository, so that later you can use the mqsirestoreconfigmgr command should the CM become damaged.
The instructions on how to recover are here:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/an04370_.htm
You'll notice that they give instructions on how to recover if you don't have a backup. In WMB 6.1 its possible to create a brand new CM and have it "adopt" the existing Brokers.
I was going to cron the backup of the CM and just be ready in case I ever need to use mqsirestoreconfigmgr, but then the following questions came up:
How often will I run mqsibackupconfigmgr? Once a week? A night? Only after a deploy? In DEV deploys are happening constantly all day long, so is once a night enough? In PROD deploys only happen once a month or so, so is once a night overkill?
The command help says the CM should be stopped. No bid deal, add mqsitop to the script. But it also wants there to be no deploys in progress. So how do you consistently and accuratly insure that in a script?
All of the sudden that trivial mqsibackupconfigmgr script is complicated. And then you think about the fact that you can adopt a broker with a brand new CM it makes me wonder, is it worth backing up the Config Manager? What do you guys do? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Dec 04, 2008 11:44 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Peter,
The short answer is YES.
The longer answer is still Yes and do it on a daily basis.
How you do it, is another question.
If your deploys are stable then normally, I'd just stop the configMgr and backup the whole ConfigMgr DB Tree. You are using a specified directory for the DB aren't you?
(I know of several PRODUCTION systems that are running on the OOTB Default Broker/configMgr QM,DB, Broker & CM Configuration)....
I agree that the V6.1 functionality to 'adopt' a broker is useful but I'd rather use a traditional backup method first.
Like some of the mqsi... utilities, the first releases were somewhat problematical so if I were you I'd not have to depend upon this 'adopt a broker' functionality in a prod environment until I was comfortable that it would work when I wanted it to (ie in an emergency with PHB's wanting it all fixed yesterday).
That said, I'm doing a customer upgrade shortly where I hope to use this facility. We do have lots of time available for testing though. _________________ 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 |
|
 |
mqmatt |
Posted: Fri Dec 05, 2008 4:00 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
One thing to bear in mind is that broker adoption and synchronization doesn't quite discover everything about a running broker: particularly, it doesn't synchronize deployed artefacts that aren't message flows (i.e. dictionaries, JARs, XSL and adapter connection files).
OK, so you can't actually do much with these artefacts from the ConfigMgr other than view or delete them, but if you need to rebuild your domain using broker adoption, then you'll lose the information of which of these objects are deployed where. Which might be important for you. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Dec 05, 2008 5:40 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Even if you mqsirestoreconfigmgr from a mqsibackupconfigmgr, the manual says:
Quote: |
you must also redeploy the domain configuration to ensure that the configuration across the broker domain is consistent. |
What exactly does that mean? Right Click on Broker Toplogy and select "Deploy Topology Configuration...Complete"? Maybe not as that brings up hits related to Pub Sub and we aren't using that. How do you "redeploy the domain configuration"? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 05, 2008 6:26 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
I was just going to ask about collectives. I believe this would be another reason why you would want to back up the config mgr.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqmatt |
Posted: Fri Dec 05, 2008 6:31 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
The topic is wrong, I'll get it changed. Step 9 shouldn't be there, and steps 5 and 6 are round the wrong way.
In this scenario you don't need to do any redeploy of the domain configuration. You only need to do a deployment (a complete topology deploy works fine) if you've moved the CM onto a different queue manager. That's because you need to tell the brokers to start sending status messages to a new queue manager.
-Matt |
|
Back to top |
|
 |
mqmatt |
Posted: Fri Dec 05, 2008 6:33 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
fjb_saper wrote: |
I was just going to ask about collectives. I believe this would be another reason why you would want to back up the config mgr.  |
Correct, all pub/sub topology information is controlled solely by the CM. Each broker only knows its immediate neighbo(u)rs. You can only get the topic tree through the CM, too. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 05, 2008 6:48 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mqmatt wrote: |
fjb_saper wrote: |
I was just going to ask about collectives. I believe this would be another reason why you would want to back up the config mgr.  |
Correct, all pub/sub topology information is controlled solely by the CM. Each broker only knows its immediate neighbo(u)rs. You can only get the topic tree through the CM, too. |
Topic trees can be exported/imported and redeployed. I believe however that you would have to recreate the collectives if you did not backup the config mgr.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqmatt |
Posted: Fri Dec 05, 2008 7:27 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
Alternatively, move to MQ v7  |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 05, 2008 7:29 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mqmatt wrote: |
Alternatively, move to MQ v7  |
Is MQ V7 now certified with WMB V6/V6.1?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Dec 05, 2008 8:00 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Dec 05, 2008 8:07 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
mqmatt wrote: |
The topic is wrong, I'll get it changed. Step 9 shouldn't be there, and steps 5 and 6 are round the wrong way.
In this scenario you don't need to do any redeploy of the domain configuration. You only need to do a deployment (a complete topology deploy works fine) if you've moved the CM onto a different queue manager. That's because you need to tell the brokers to start sending status messages to a new queue manager.
-Matt |
Thnaks for the clarification.
So when you back up a CM and restore it, you are restoring that CM's view of what Brokers it has, what EGs those Brokers have, and what flows and sets those EGs have?
The Broker does not have the final say in what is has deployed, the Configuration Manager has the final word when it comes time to display what a Broker has? And the CM, either a new one or a stable existing one can't "pull" this info from a running Broker to present an accurate view in the Toolkit? Seems a little backwards, but its obvious I don't understand what's going on under the covers. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 05, 2008 1:48 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Peter, I'd see the CM as a kind of cache receiving the delta updates from the registered brokers. So the information you are displaying always comes from the cache. Interrogating the brokers in the domain every time would consume too many resources....
But then maybe I'm completely off track...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqmatt |
Posted: Mon Dec 08, 2008 3:15 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
PeterPotkay wrote: |
The Broker does not have the final say in what is has deployed, the Configuration Manager has the final word when it comes time to display what a Broker has? And the CM, either a new one or a stable existing one can't "pull" this info from a running Broker to present an accurate view in the Toolkit? Seems a little backwards, but its obvious I don't understand what's going on under the covers. |
Historically, it has been the case that the CM has the final say of what domain information is shown.
One of the important changes in v6.1 is to largely reverse this power; the CM is now able to query the broker to ask it what it is actually running, and for the CM to update its definitions and report back to the toolkit accordingly.
However, the CM still can't query the presence of dictionaries, JARs, XSL files and adapter connection files - this information is determined solely from what that CM has successfully deployed, and not from the broker itself. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Dec 08, 2008 7:51 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
mqmatt wrote: |
However, the CM still can't query the presence of dictionaries, JARs, XSL files and adapter connection files - this information is determined solely from what that CM has successfully deployed, and not from the broker itself. |
And so this is why you would want to rely on backups and restores of the CM using the provided commands versus adopting a brker with a new CM? A restored CM will show the dictionaries, JARs, XSL files and adapter connection files, whereas a new CM with an adopted Broker would need a redeploy of these objects to get in sync. The redeploy would only be needed to resync the view; the actual Broker would continue to run fine with all the resources while you futz around with the new CM and the adoption papers for your orphaned Broker(s)? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|