Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-24850

Convert log_warnings from numeric level to feature mask

Details

    • Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      When checking

      https://mariadb.com/kb/en/server-system-variables/#log_warnings

      I see a total of 28 different things that can be logged as warning across the different log_warning levels.

      Sometimes you might be interested in warnings of higher levels, like e.g.

      "Connections aborted due to "Too many connections" errors. " (level 4)

      but not in lower level warnings. Especially

      "Aborted connection ... (Got an error reading communication packets)" (level 2)

      comes to mind, as some installations have clients that just disconnect without prior mysql_close() and can't do anything about it, e.g. when not having access to application source code.

      So error log can be spammed with "Aborted connection ..." messages, making it hard to check for actual problems, but at the same time lowering the log_warning level to 1 to get rid of "Aborted connection ..." log lines would also hide other warnings completely.

      Given the amount of different warning types covered by log_warnings logic by now, it seems to be about time to convert log_warnings into a feature list / mask instead, where individual options can be set and removed, like we e.g. have it with sql_mode and optimizer_switch settings.

      The current warning level numbers could still be supported in such a scheme, by making them shortcuts that combine several options, similar to e.g. the TRADITIONAL option in sql_mode ...

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            Thanks hholzgra.

            Do you have a set of defined masks that would be useful? Or a set of shortcuts?

            Other considerations journald can make an arbitrary tags for ease of searching that could be incorporated here (and seems docker/podman accept this form of log too). Systems/subsystem could be done. A mapping to a flat file probably still needs to be done.

            Which of the MySQL-8.0 log event fields do you like/dislike?

            danblack Daniel Black added a comment - Thanks hholzgra . Do you have a set of defined masks that would be useful? Or a set of shortcuts? Other considerations journald can make an arbitrary tags for ease of searching that could be incorporated here (and seems docker/podman accept this form of log too). Systems/subsystem could be done. A mapping to a flat file probably still needs to be done. Which of the MySQL-8.0 log event fields do you like/dislike?

            I have not really looked into how MySQL 8 handles this at all.

            This request was mostly based on seeing user error logs where 99%+ of all log lines were due to clients either disconnecting without proper close message, or running into wait_timeout, quite often, and the only way to prevent this right now being to lower log_warnings to one or zero, so also hiding other warnings.

            hholzgra Hartmut Holzgraefe added a comment - I have not really looked into how MySQL 8 handles this at all. This request was mostly based on seeing user error logs where 99%+ of all log lines were due to clients either disconnecting without proper close message, or running into wait_timeout, quite often, and the only way to prevent this right now being to lower log_warnings to one or zero, so also hiding other warnings.

            People

              Unassigned Unassigned
              hholzgra Hartmut Holzgraefe
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.