MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Mark Leith Date:July 23 2009 12:04pm
Subject:Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)
View as plain text  
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:

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.



Mark Leith
MySQL Regional Support Manager, Americas
Sun Microsystems, Inc.,

bzr commit into mysql-5.1-bugteam branch (luis.soares:3024) Bug#42851Luis Soares18 Jul
  • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Davi Arnaut19 Jul
    • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Sergei Golubchik19 Jul
      • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Luís Soares20 Jul
        • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Davi Arnaut20 Jul
          • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Konstantin Osipov20 Jul
          • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Mark Leith23 Jul
    • Re: bzr commit into mysql-5.1-bugteam branch (luis.soares:3024)Bug#42851Luís Soares20 Jul