Hi All,
On 20 Jul 2009, at 19:05, Davi Arnaut wrote:
> Hi Luís,
>
> On 7/20/09 6:48 AM, Luís Soares wrote:
>> Hi Davi, Sergei,
>>
>> Thanks for the comments. Please, find below my reply and let me
>> know
>> if you have more feedback.
>>
>> Regarding Davi's suggestions:
>>
>> D1. Pipe through script - Thanks for point this out, it did not
>> occur
>> to me actually. However, I think this would be the workaround
>> for
>> this bug, would it not? Furthermore, support requested that the
>> server should provide some mechanism to avoid flooding error log
>> files.
>
> Not everything has to be in the server..
I agree with this - but for this specific issue I think using some
piping script to do the filtering is a little hackish, and we *should*
enable some way to not see these warnings. That's really what
"log_warnings" was supposed to be about right?
>> D2. Rate limit messages - This might kind of work if not limiting
>> per
>> session/user.
>>
>> If limiting per user/session, and in a web scenario where lots
>> of
>> short lived sessions are going on, with lots of different users,
>> taking such approach would not solve the initial problem, as the
>> log would be full of warnings anyway.
>
> I meant per-message rate limiting.
We do similar things with MEM ("last error repeated X times"), but
then, we also have increasing logging levels too (debug, critical,
warning, note, etc.).
>> On the other hand, if not limiting per user/session, then the
>> problem may be masked, but it would still be there. For
>> instance,
>> some applications force usage of 'limit 1', thence the log would
>> probably still grow at a smaller but impracticable rate in the
>> long run)... Thus, as I see it, this could be an option if
>> parameters for controlling rate of printouts were provided by
>> the
>> server. This way, the DBA would be able to configure and fine
>> tune rate limit according to their workload.
>
> If the problem is a DoS due to some malicious user being able to
> repeatedly trigger some message that gets logged, rate limiting
> effectively fixes the problem.
There are two issues:
o DoS
o Customers actually verify that the set up they have is working how
they expect it to, and consider the warnings as spam - they already know
>> Regarding Sergei's suggestion:
>>
>> S1. log if log_warnings> 0 - "Unsafe statement" is a serious
>> replication warning, as such (and as it is today) it is printed
>> even without checking log_warnings value. Also, the default
>> value
>> for log_warnings is 1, meaning that if considering this option
>> and setting warning printout to only happen when
>> log_warnings> 2
>> or even 3, we would be implicitly decreasing its level/severity
>> (I am not very keen on decreasing it).
>>
>> Furthermore, log_warnings actually controls whether to output or
>> not, sets of messages (per level/severity). So if decreasing
>> severity for unsafe warnings, and the DBA wanted the output of
>> unsafe warnings, then he would have to set log_warnings=2(3?)
>> which would cause output of warnings he did not necessarily want
>> or need.
>
> Has any user actually requested finer grained filtering?
Plenty have complained about the lack of being able to disable these
warnings all together - see another bug that I opened up for this:
http://bugs.mysql.com/bug.php?id=42851
In it I actually proposed the most simple fix that Sergei suggested as
well - just check log_warnings > 0. I.e we *do* print it by default
(just so everybody is aware, better safe than sorry, etc.) - but still
give the facility to disable them.
Lots of customers have brought this up in the past.
>> Just a side note. I agree that, if decreasing severity is an
>> option, the fix for this bug using log_warning is "dead simple",
>> but with the aforementioned side-effects.
>>
>> So, IIUIC:
>>
>> - D1 is a workaround, not a fix.
>
> OK..
>
>> - D2 and S1 could help in reducing log flooding. D2, might require
>> some parameters to be provided by the server (like period and
>> number of messages). S1, might require decreasing warning
>> severity.
>
> Doesn't need to be configurable. We just stipulate that certain
> messages will be printed at most N times per second and be done with
> it.
>
>> - Neither, D2 or S1 provide the ability to selectively and
>> completely
>> suppress specific warnings from error log.
>
> Why should we provide this? There isn't a compelling reason so far.
In 5.1 I don't think so - but I also added logging of "access denied"
errors with log_warnings as well in 6.0, and I think there's a number
of things that should/could be added to log_warnings, should we have a
better facility to mask certain warnings.
I'm all for this proposal, for the record. I'm still happy with a
"quick and dirty" fix of log_warnings > 0 for 5.1 for this specific
issue as well though.
Cheers,
Mark
--
Mark Leith
MySQL Regional Support Manager, Americas
Sun Microsystems, Inc., http://www.sun.com/mysql/
