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..
> 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.
> 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.
> 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?
> 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.
