huge .log file in /usr/share/cagefs-skeleton/var/lib/mysql/

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • zodiac9797
    Junior Member
    Forum Explorer
    • Mar 2021
    • 22

    #1

    huge .log file in /usr/share/cagefs-skeleton/var/lib/mysql/

    Hi,
    I've noticed that I'm missing some disk space and today I started with the investigation.

    At the end I found out that there is a huge 2TB log file inside:
    /usr/share/cagefs-skeleton/var/lib/mysql/server_name.log

    I've checked the file and it contains all MySQL queries sent from the websites on the server and some additional stuff like MySQL connections...

    Questions:
    - how do I maintain this log file? rotation? limits?
    - why there is no default limit?
    - what to do now? can I just delete it? or truncate it? or something else?

    Please advise. 🤔
  • bogdan.sh
    Administrator
    • Nov 2016
    • 1286

    #2
    The file is almost certainly a MySQL general query log (or similar). What is inside that log file? Please do not open it with vi, but check the last few lines with:

    Code:
    tail -100 /usr/share/cagefs-skeleton/var/lib/mysql/server_name.log

    Check MySQL global variables:

    Code:
    mysql -e "SHOW GLOBAL VARIABLES LIKE 'general_log%'; SHOW GLOBAL VARIABLES LIKE 'general_log_file';"2)

    I guess you have it enabled somewhere in mysql configs, so check:
    Code:
    grep general_log /etc/my* -Rs
    Please do not delete this file as is, better to find why it is there, disable and only then do actions. Either by truncating it ro rotating with logrotate (which is always a best choice).

    Comment

    • zodiac9797
      Junior Member
      Forum Explorer
      • Mar 2021
      • 22

      #3
      Originally posted by bogdan.sh
      The file is almost certainly a MySQL general query log (or similar). What is inside that log file? Please do not open it with vi, but check the last few lines with:

      Code:
      tail -100 /usr/share/cagefs-skeleton/var/lib/mysql/server_name.log
      File contains mySQL queries made by websites on our server, like:
      1440 Query SELECT * FROM DB_NAME WHERE ...
      It looks like every query from the beginning is "saved" in this log.


      Check MySQL global variables:

      Code:
      mysql -e "SHOW GLOBAL VARIABLES LIKE 'general_log%'; SHOW GLOBAL VARIABLES LIKE 'general_log_file';"2)
      +------------------+--------------------------+
      | Variable_name | Value |
      +------------------+--------------------------+
      | general_log | ON |
      | general_log_file | /var/lib/mysql/server_name.log |
      +------------------+--------------------------+
      +------------------+--------------------------+
      | Variable_name | Value |
      +------------------+--------------------------+
      | general_log_file | /var/lib/mysql/server_name.log |
      +------------------+--------------------------+


      I guess you have it enabled somewhere in mysql configs, so check:
      Code:
      grep general_log /etc/my* -Rs
      /etc/my.cnf:general_log=1

      Please do not delete this file as is, better to find why it is there, disable and only then do actions. Either by truncating it ro rotating with logrotate (which is always a best choice).
      I won't, I am aware that deleting log file is a wrong approach. I can truncate it but it will grow again, I would be happier if I know where are the settings related to it so I can alter them and/or set logrotate.

      Comment

      • zodiac9797
        Junior Member
        Forum Explorer
        • Mar 2021
        • 22

        #4
        Don't know how to edit my previous post...

        UPDATE: Now I understand that it's the "general_log=1" that's recording all queries to the server_name.log file. I will just set it to "general_log=0" since I don't need all this info. Slow queries log is enough. Current 2TB log file I will just truncate, I won't need rotation since I will turn off this option.

        Did I get it right?

        Comment

        • bogdan.sh
          Administrator
          • Nov 2016
          • 1286

          #5
          Yup that's correct!

          Comment

          Working...