| Author |
Message
|
| wskibum |
 Posted: Tue Mar 15, 2011 10:37 am Post subject: MQ 7 Backup QMGR questions |
 |
|
Apprentice
Joined: 03 Jul 2008
Posts: 38
Location: Northern California
|
I have setup a backup QMGR for our primary MQ server. I am shipping log files to it and using the strmqm -r QM1 to read in the logs.
How can I validate its reading the logs? Can I look at queues, etc somehow?
If I activate the QMGR with strmqm -a can I go back to using the -r option and return its status to a backup ?
Does anyone know of good documentation on managing a backup QMGR? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Mar 15, 2011 11:16 am Post subject: Re: MQ 7 Backup QMGR questions |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| wskibum wrote: |
I have setup a backup QMGR for our primary MQ server. I am shipping log files to it and using the strmqm -r QM1 to read in the logs.
How can I validate it's reading the logs? Can I look at queues, etc somehow? |
You can't, but if there was an issue with an unreadable log I'm sure an error message would be displayed...
| wskibum wrote: |
| If I activate the QMGR with strmqm -a can I go back to using the -r option and return its status to a backup ? |
Go look in the Info Centre, the answer is quite explicit...
| wskibum wrote: |
| Does anyone know of good documentation on managing a backup QMGR? |
Yes. It's called the Info Centre.
And remember the only way to ensure a consistent 'back-up' is to stop the queue manager from processing anything, and then shut it down. Otherwise all you have is a 'fuzzy' back-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 |
|
|
| wskibum |
| Posted: Tue Mar 15, 2011 11:32 am Post subject: |
|
|
Apprentice
Joined: 03 Jul 2008
Posts: 38
Location: Northern California
|
Sorry, I thought I had done a pretty good job looking thru the Info Center docs.
It covers starting a backup qmgr but I have not seen anything on rolling it back.
This is a DR solution, we will test failovers every quarter from production, if the backup qmgr won't fail back and forth I need to know what to do.
Thanks for any suggestions. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 15, 2011 1:17 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The third sentence of step 1. on THIS page couldn't be any clearer, as well as the last sentence of the last paragraph on THIS page.
If you are having to resort to a back-up the last thing you should be worrying about is how to recover that back-up to a previous state, your focus should be recovering the primary and then reinstating the DR infrastructure. So, want to guess what you'll do with your DR back-up once your primary is back up and running, maybe consider a brief role-reversal of the two queue managers?
_________________
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 |
|
|
| wskibum |
| Posted: Tue Mar 15, 2011 1:29 pm Post subject: |
|
|
Apprentice
Joined: 03 Jul 2008
Posts: 38
Location: Northern California
|
Thank you very much very much! I compltely overlooked that last line.
Yes, in the event of DR failover the plan was to rebuild the production server and then ship logs in the opposite direction.
So at the end of this event and we move back to production I will need to rebuild the backup qmgr again in DR.
I am not getting any errors when I fire up the backup qmgr to read in the logs so I will assume all is well. I am new to MQ so I appreciate all your help. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 15, 2011 1:35 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Welcome to the 'cluster' 
| wskibum wrote: |
| I am new to MQ so I appreciate all your help. |
You'll always be new to WMQ - it's a moving target! Damn thing's like an eel, every time I think I have a hold on it the egg-heads at Hursley add another twist and it gets away from me again! 
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Mar 15, 2011 2:17 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| wskibum wrote: |
| in the event of DR failover the plan was to rebuild the production server and then ship logs in the opposite direction. |
Generally in a DR situation where the DR site is not using some sort of dynamic mirroring, production servers are rebuilt with MQ having empty logs and empty queues. This is so that production apps running in DR are not faced with an inconsistent situation where there could be duplicate messages processed, with possibly serious consequences for the business. Later, when the primary server comes back to life and processing moves back, any persistent queued messages should still be there and they can be processed.
| Quote: |
| I am not getting any errors when I fire up the backup qmgr to read in the logs so I will assume all is well. I am new to MQ so I appreciate all your help. |
I assume you stop the primary queue manager before you take a copy of the logs?
_________________
Glenn |
|
| Back to top |
|
|
| wskibum |
| Posted: Tue Mar 15, 2011 2:28 pm Post subject: |
|
|
Apprentice
Joined: 03 Jul 2008
Posts: 38
Location: Northern California
|
| No, we force the qmgr to jump to the next log and then ship the log it was using. I have a script that does this every 5 minutes. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 15, 2011 2:34 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| wskibum wrote: |
| No, we force the qmgr to jump to the next log and then ship the log it was using. I have a script that does this every 5 minutes. |
Not looking for consistency then?
_________________
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 |
|
|
| wskibum |
| Posted: Tue Mar 15, 2011 2:37 pm Post subject: |
|
|
Apprentice
Joined: 03 Jul 2008
Posts: 38
Location: Northern California
|
We can afford to loose 5 minutes of data.
Do you suggest another solution? Any help or suggestion is appreciated.
BTW we will have SAN replication in a year so this is supposed to be the interim solution. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 15, 2011 2:45 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The only way to take a proper back-up, be it logs and/or file system, is to stop anything using the queue manager (and that included message channel agents) and end the queue manager. Of course it will only be setting a point-in-time consistency, so no, I don't really have any suggestions. If you're prepared for @5 minutes loss and deemed it acceptable, then you're doing pretty much all you can already.
And even SAN replication is going to leave you slightly lagging behind the 'now' instant...
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Mar 15, 2011 3:44 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Using the official Backup QMs in MQ, the primary is going to ship the latest log over to the backup when it cuts a new log. Once that happens, and until the next one comes across, you may be getting more and more behind, but at least you have a consistent QM in the back up QM.
With large log files and /or a low level of activity to even small logs, you may find the QM cutting new logs very infrequently, and therefore may find your Back Up QM quite far behind.
With asynchronous SAN replication, all bets are off. The SAN replication doesn't care where the QM is in its log processing as it sends bits of data over. I have to think at best you will find your DR QM with missing messages and/or duplicate message. At worst the logs may be unusable and you might have to rebuild the QM.
With synchronous SAN replication, you either don't have a true DR solution because your DR site is not far enough away, or a very poor performing production environment as you wait for the (very) remote SAN to acknowledge you for every write.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 15, 2011 3:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
| The only way to take a proper back-up, be it logs and/or file system, is to stop anything using the queue manager (and that included message channel agents) and end the queue manager. |
I don't know if that statement is entirely true when dealing with Back Up QMs.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.amqzag.doc/fa14740_.htm
| Quote: |
To ensure that a backup queue manager remains an effective method for disaster recovery it must be updated regularly. Regular updating lessens the discrepancy between the backup queue manager log, and the current queue manager log. There is no need to stop the queue manager to be backed up.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wskibum |
| Posted: Tue Mar 15, 2011 3:49 pm Post subject: |
|
|
Apprentice
Joined: 03 Jul 2008
Posts: 38
Location: Northern California
|
| I am forcing the Production QMGR to switch logs every 5 minutes, regardless of trafic. We were concerned about that large lag time if traffic was slow, thats why we adopted forcing the log to switch with runmqsc RESET QMGR TYPE(ADVANCELOG) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 15, 2011 3:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| wskibum wrote: |
| I am forcing the Production QMGR to switch logs every 5 minutes, regardless of trafic. We were concerned about that large lag time if traffic was slow, thats why we adopted forcing the log to switch with runmqsc RESET QMGR TYPE(ADVANCELOG) |
Your solution to run that command every 5 minutes is simple. You may occasionally run the command 1 second after the log rolled over, but oh well.
Ya know, I wonder why there isn't a built in parameter that allows the MQ Admin to tell the QM how often to force the advance log if it hasn't done it just because of normal application activity. This way you wouldn't have to mickey mouse the running of the command by some other process (something else to break), and you would avoid running the command those times where the log already rolled naturally.
Back Up QMs are not used very much, at least by the people that post here. I might be wrong on this, but you are the first one that I remember that is actually using it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
