| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Backup strategies |
« View previous topic :: View next topic » |
| Author |
Message
|
| vchenna |
 Posted: Mon Jul 13, 2009 11:00 am Post subject: MQ Backup strategies |
 |
|
Novice
Joined: 29 Jun 2009
Posts: 18
|
We are currently backing up the MQ servers.
Can someone provide best practices for how we should backup MQ servers? i.e. which directories, how often, etc…
Thanks
VJ |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jul 13, 2009 11:06 am Post subject: Re: MQ Backup strategies |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vchenna wrote: |
Can someone provide best practices for how we should backup MQ servers? i.e. which directories, how often, etc…
|
If you're following best practice there shouldn't be any messages left on queues to require backing up.
System level backup should be /var/mqm; if (again) you're following best practice and the linear logs are on a separate device this doesn't need to be done all that often. Exactly how often depends on your site standards. My experience (for what this is worth) is that the WMQ servers are backed up in this way once a quarter as part of the server backup, with specific housekeeping more frequent.
I've also seen the WMQ servers not backed up at all, but that site was fairly tight on build standards and scripts.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 13, 2009 2:59 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Backup for what purpose? DR? Application (message) backup? WMQ object backup definition backup?
How often will be dictated by your application design, message rate and toleration to data loss.
Good (excellent) application design implies that once a message is put to a queue, it is consumed instantaneously. Thus, no messages will be left in queues. A catastrophic failure (loss of data center or server) will require reinstalling WMQ and recreating your local objects (and application programs and databases).
If messages sit in queues for extended periods (minutes, hours, days) then you are at risk of losing messages. Good (excellent) application design implies applications can tolerate lost or duplicated messages - that applications will redrive the transactions lost or duplicated messages.
_________________
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 |
|
|
| gbaddeley |
| Posted: Mon Jul 13, 2009 5:14 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
Backup for what purpose? DR? Application (message) backup? WMQ object backup definition backup?
How often will be dictated by your application design, message rate and toleration to data loss. |
Yes, we need to know the requirements before recommending a backup strategy.
| Quote: |
Good (excellent) application design implies that once a message is put to a queue, it is consumed instantaneously. Thus, no messages will be left in queues. A catastrophic failure (loss of data center or server) will require reinstalling WMQ and recreating your local objects (and application programs and databases).
If messages sit in queues for extended periods (minutes, hours, days) then you are at risk of losing messages. Good (excellent) application design implies applications can tolerate lost or duplicated messages - that applications will redrive the transactions lost or duplicated messages. |
A nice ideal but in practise it never works out that way. Its almost sure as eggs there will be some application messages queued at the time of a backup. If the backup is going to be used to restore or rebuild the MQ environment (in DR or some other partial-failure situation), the recommendation is to clear out all app messages before handing MQ over to the apps, unless some special arrangement has been made.
If you are going to backup the MQ file systems make sure the Queue Managers are shutdown at the time, otherwise the backups may be invalid (if you try to use them the Queue Managers may not start).
_________________
Glenn |
|
| Back to top |
|
|
| sumit |
| Posted: Tue Jul 14, 2009 4:42 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| gbaddeley wrote: |
| If you are going to backup the MQ file systems make sure the Queue Managers are shutdown at the time, otherwise the backups may be invalid (if you try to use them the Queue Managers may not start). |
Indeed. Except when you are using fuzzy backup.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 14, 2009 5:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Its almost sure as eggs there will be some application messages queued at the time of a backup. |
My point exactly. And I learned this (missing data) mostly from DR exercises.
This is why I've pushed for application developers to ensure that they have sufficient backups for routine data loss (corrupt file or queue) and catastrophic loss.
I feel strongly that it is the sysadmins responsibility to recover the infrastructure (o/s and subsystems), and the app developers responsibility to recover lost user-data.
In the old days, we'd just shut down and back up the server. With 24x7 availability, that's seldom possible. Fuzzy backups are, well, fuzzy.
Are messages all that is required to recover an entire application? Likely not.
For any given application, developers must inventory what 'all their data' comprises, keep the inventory up-to-date, and create appropriate backup methodology (programs, utilities).
_________________
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 |
|
|
| vchenna |
| Posted: Tue Jul 14, 2009 6:03 am Post subject: Thanks |
|
|
Novice
Joined: 29 Jun 2009
Posts: 18
|
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 14, 2009 6:19 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And bear in mind that any backup is out of date the moment after you have taken it, so backing up an 'empty' queue manager may be considered to be a fruitless exercise, especially as the queue manager can be backed up any time using MS03 (I know that's object attributes only!).
I'm with bruce2359 on this one, have a rapid-rebuild script to hand, and shove the responsibility for the data back where it belongs - the application.
_________________
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 |
|
|
| ramires |
| Posted: Tue Jul 14, 2009 6:54 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
This subject can take us to a long discussion, I've worked with mq installations where queues are used as a message deposit during business hours, to be consumed during the night by batch programs.
Also we have xmit queues with thousand of messages wating for a remote queue manager to be available.
In practice there aren't empty queue managers
Regards |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 14, 2009 7:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes, messages left in queues by applications, and messages sitting on xmit queues, are subject to loss. WMQ is not a database, not a good solution for long-term message/data storage.
WMQ architecture doesn't anticipate catastrophic failure. If your organization requires higher availability than Win and UNIX provide, look at WMQ for z/OS and GDPS (Geographically Dispersed Parallel Sysplex).
MQ is a pipe through which messages, like water, flow. I put water in one end and, I hope, it comes out the other end. If for any reason it doesn't, then what?
Good application design should include the ability to detect and handle lost or duplicated data. WMQ applications - data = messages. (I've harped on this extensively in other posts).
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jul 15, 2009 12:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
(I know that's object attributes only!).
|
Slightly more than that with later versions - you get OAM as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 15, 2009 12:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| WMQ is not a database, not a good solution for long-term message/data storage. |
| bruce2359 wrote: |
| Good application design should include the ability to detect and handle lost or duplicated data. WMQ applications - data = messages. (I've harped on this extensively in other posts). |
And I think I disagreed with you there as well. The point of WMQ is it's an assured delivery system. The application should not have code to check for lost or duplicated data any more than it checks for lost or duplicated data in a database. Such problems (and their prevention) are the job of the DBA. Likewise preventing "the water leaking" is a job for the WMQ admin, not the application.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jul 15, 2009 12:44 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
(I know that's object attributes only!).
|
Slightly more than that with later versions - you get OAM as well. |
Agreed, but I treat them as one and the same thing 
_________________
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 |
|
|
| ramires |
| Posted: Wed Jul 15, 2009 1:38 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| bruce2359 wrote: |
MQ is a pipe through which messages, like water, flow. I put water in one end and, I hope, it comes out the other end. If for any reason it doesn't, then what? |
... then you need a water deposit, to accumulate the water, like a queue to accumulate messages, temporally
The performance decrease in a logarithmic trend with the number of messages in a queue, and I agree: MQ is not a Database!
The example of the sales man, using a mq client, connecting to a qmgr server at the end of his work day to receive msgs stored in a dedicated queue, makes use of this approach. Some MQ shops do this kind of solution's
Regards |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 15, 2009 6:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
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.
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?
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?
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.
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.
The appropriate number recovery methods is: one more than you need, whatever that number might be.
_________________
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 |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
