| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Is CIRCULAR logging plus RAID really good enough? |
« View previous topic :: View next topic » |
| Author |
Message
|
| dutchman |
 Posted: Thu Jun 13, 2002 5:12 am Post subject: Is CIRCULAR logging plus RAID really good enough? |
 |
|
Acolyte
Joined: 15 May 2001
Posts: 71
Location: Netherlands
|
Howdy - we all know that circular logging is a lot easier to manage than linear, but that linear logging provides us with the possibility of recovering from damaged objects.
I, however, want the best of both worlds, i.e. circular with recoverability of damaged objects.
After a discussion with the Unix dba I've discovered that the disks are mirrored. This is good as it ensures that any hardware failures are handled. However, MQSeries damaged objects may not be caused by a hardware failure, so I believe that in such an instance both the main disk and its mirror hold a damaged object.
In other words, circular logging with mirrored disks do not avoid damaged objects.
Please respond with your thoughts and opinions, and - even better - a confirmation that you're running circular with mirorred disk in production. |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu Jun 13, 2002 5:38 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well I have worked with MQSeries in production enviroment for 4 years with circular logging(30+Qmgrs), we have used EMC/Raid disks, we have had damaged objects which can cause some grief such as:
1) Finding which object is truely damaged
2) If there was data in the Queue ( we had provisions for resends)
That said though we only have had maybe 3 instances of corrupted objects and that was with version 5.0 of MQSeries on HPUX, I dont
recall any damaged objects on v5.1 or v5.2 (that doesnt mean it cant happen)
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Jun 13, 2002 5:43 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
IMHO linear logging causes more problems than it solves.
It is a hangover from the days when disks were less reliable (and not so cheap), and before RAID/mirror disk technology was widespread.
Those were the days when people talked about 300Mb disk drives being "large". Then one day I put a 300Mb drive in the back pocket of my jeans and realised it didn't weigh 200kg anymore.
I have seen production implementations, in MANY different sites, that do not use LL - they have circular logs and RAID-5 disks.
The few times when I have seen it is needed is when MQ logically corrupts a queue. Then you need to delete the q file from the operating system and recover the object using rcrmqobj.
(This is purely In My Humble Opinion - if you RTFM IBM tells you to use linear logging)
HTH
Don |
|
| Back to top |
|
|
| jhalstead |
| Posted: Thu Jun 13, 2002 6:11 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
A few thoughts, is linear logging really that much hassle to administer? I don't think so. You 're always going to need to shut MQ down to do a consistent back up so it's a little extra work to shut down channels, take a media image and then archive off old logs....
The real question has to be how important is the data, is a batch of lost messages acceptable, can the applications involved reconcile the differences and re-send as necessary? At the end of the day your just trying to make MQ as robust as possible.
Jamie |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Jun 13, 2002 6:24 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Again, my personal opinion, but how often is LL used?
And, in a recovery situation, recovering all messages and replaying transactions twice can, in some cases, be more dangerous than losing them from the queue....
The only good queue is an empty queue!
And, I have seen a situation where a long-running transaction has caused the number of active logs to exceed 63, effectively blowing up the queue manager. With circular logging, it wouldhave merely been roled back....
Also, if your housekeeping DOES fail, and you fill the disk up, then you end up with the queue manager unusable in one form or another anyway....
If IBM supplied a better set of housekeeping utilities rather than the supportpack, shareware, unsupported PERL script - then LL could be taken seriously....
Purely my own opinion.... |
|
| Back to top |
|
|
| dutchman |
| Posted: Thu Jun 13, 2002 12:40 pm Post subject: |
|
|
Acolyte
Joined: 15 May 2001
Posts: 71
Location: Netherlands
|
Thanks for the opinions. It seems that from the experience of mrlinux that my asumption was correct: you can get damaged objects even with raid disks. 
I've never had a damaged object, but have seen posts on the MQ listserver of people who have had them. The question is: how likely is it to happen, and if it happens can you somehow get the important message back - possible as was suggested by some kind of 'replay' action.
Dgolding comment 'The few times when I have seen it is needed is when MQ logically corrupts a queue. Then you need to delete the q file from the operating system and recover the object using rcrmqobj' only works of course if you used LL. I agree that disks are a lot more reliable these days, but that is not really the main point here. You can get damaged objects on reliable disks! 
Regarding the comment from jhalstead, at the moment we are preparing for production - i.e. the first prod implementation. The system on Sun has been set up to use 'crontab' which basically runs a script on a Sunday to do the usual 'rcdmqimg' of all objects followed by 'cleanmqlogs'. However, the environment is currently being used for testing with an inordinate amount of test data - to the tune that in a 3 minute period, 4 lots of logs each sized at 33MB being used up. It doesn't take too long to fill up the file system, so we've got to come up with a better solution than the 'once a week' one.  |
|
| 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
|
|
|
|
