| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Backup strategies |
« View previous topic :: View next topic » |
| Author |
Message
|
| Vitor |
 Posted: Wed Jul 15, 2009 7:20 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Although I've seen very few well-designed apps (sensitive to data loss/duplication), I still set this as a goal - for both MQ and non-MQ applications. |
Also database & non-database applications?
| bruce2359 wrote: |
| With thousands or millions of messages lounging in queues for hours or days, recovery time (log replay) following a qmgr failure will impact restart time. Can other applications tolerate this delay? Can my SLA commitment to uptime (and my career) tolerate this delay? |
If your WMQ applications are properly decoupled, then the delay between transmission and delivery is irrelevant to the design of the application; again this is a matter for the WMQ admin.
Also no-one here is saying that messages should be lounging in a queue. Indeed, I think the opinion of this thread is exactly the contrary.
| bruce2359 wrote: |
| Non-MQ applications obviously don't benefit from the wonderful recovery-restart message preservation assured by logging. Why should the bar be lowered for non-MQ applications? |
If you have non-MQ applications then this whole debate is irrelevant. Any application that does not use WMQ's assured delivery mechanism of course has to worry about the limitations of the delivery mechanism it is using. This could include data loss or duplication.
But here we're discussing WMQ applications.
| bruce2359 wrote: |
| In the case of DR (a catastrophic failure), yesterdays or last weeks image backup will do little to recover application data to any reasonably current state. |
DR planning is a separate activity to application design. I personally think yesterday's image is in fact "reasonably current"; note I say DR not HA. In the event of a disaster the loss of 1 day's processing is normally acceptable because that's how far back the paper trail goes. Of course this assumes the paper trail survives the distaster.
| bruce2359 wrote: |
| To rely solely on MQ to recover application data is a recipe for disaster. Application-level backups provide another opportunity to recovery. Well-written applications provide yet another. |
It's also a recipe for distaster to assume (or even hope) that every (or any) application on the site will be well written. Sooner or later one will slip through the most rigorous QA procedure. Better to leave these matters in the hands of a small group of admins.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Jul 15, 2009 9:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| ...If you have non-MQ applications... |
Sadly, in my (somewhat limited) experience, they are nearly all non-MQ applications, by which I mean the designers viewed WMQ as a piece of Cat 5 cable, and did not design the application for the strengths of WMQ.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jul 15, 2009 9:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
| ...If you have non-MQ applications... |
Sadly, in my (somewhat limited) experience, they are nearly all non-MQ applications, by which I mean the designers viewed WMQ as a piece of Cat 5 cable, and did not design the application for the strengths of WMQ. |
Quite, but in the context of this discussion I was drawing a distinction between applications intending to use WMQ, and applications using other methods (e.g. reading a file)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 15, 2009 10:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Quite, but in the context of this discussion I was drawing a distinction between applications intending to use WMQ, and applications using other methods (e.g. reading a file). |
Yes, I agree that my reference to non-MQ applications is outside the scope of mqseries.net.
My comments and concerns are about application developers whose apps cannot tolerate loss/duplication of data - MQ or not. This is a bad design. This is as bad a design as applications not validating the data they process.
This type of design (unfairly) places the burden and ongoing responsibility for ensuring ensuring adequate backup and recovery on sysadmins who don't normally understand their application data requirements, aren't in the loop when application data requirements change, and where messages are only part of the application data requirements.
I'll agree that sysadmins share responsibility; but app developers own the application.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
