Hi Everybody, I tried to search for a script which can moniter as well as send an alerts (by email). But i am not able to found any good scripts which can give better informations for example the complete innodb status, deadlocks, mysql errors and warnings. If any body know such script which can complete my requirement. Just Please let me know.
Thanks, -Regards, Krishna On 7/30/07, Baron Schwartz <[EMAIL PROTECTED]> wrote: > > Mark Leith wrote: > > Baron Schwartz wrote: > >> Mark Leith wrote: > >>> Baron Schwartz wrote: > >>>> I stand corrected. I don't know why I didn't think of this! > >>>> > >>>> So you guys had to go the route of parsing InnoDB status too, huh? > >>>> Fun, isn't it! > >>> > >>> Indeed, it is a rather interesting thing to do ;) Made even better > >>> when it is limited to 64K and truncated with large transactions! > >> > >> Or a big deadlock with tons of tuples. I have submitted a feature > >> request to remove the list of locks held, but I don't know how high a > >> priority it's given. It's useless for non-developers, though Heikki > >> told me he uses it every day. I wouldn't think it'd be hard to define > >> a compile-time option whether to include all the tuples locked, so > >> Heikki and Marko could see it but spare the rest of us :) Of course > >> seeing just the first part of that output, which shows what kind of > >> lock was held on which index, is very useful for non-InnoDB-developers > >> too. > > > > Have you filed a feature request on this? I would agree that the list of > > locks is certainly not of use to the average DBA, so removing this by > > default would be a good idea. > > Yes, it's here: http://bugs.mysql.com/bug.php?id=29126 > > I actually combined two bug requests in one, now that I think about > it. Maybe this > wasn't a good idea. Maybe "trim down deadlock info" and "add lock info to > normal > output" should have been separated. > > >> Yep. But there's always that legacy support you have to keep around! > > > > Exactly! ;) > > > > If 'you' have parsed the output in a sane manner, many tools should be > > unaffected, however, we can not rely on that, and changing innodb status > > could break a lot of scripts already made out there ;) This is why we > > have to be very careful and considered in making these kinds of changes. > > Of course, the burden is also on the InnoDB developers to do this. > > I don't see how this change could be made without breaking non-sane > scripts, though. > This might have to be an incompatible change for those scripts that rely > on seeing the > list of tuples. For my part, as far as I know innotop's parser should be > able to > handle it as-is, and shouldn't even care about the order in which the > sections are > placed in the output. But I'd have to make a test case to prove > that. Regardless, > support for Google's patches is on the 1.6 roadmap for innotop, so > there'll be a chance > for me to see -- but not right now, I'm too busy with other things! > > Baron >
