Why /var/log/mysql.log contain tons of lines like this:
SELECT data FROM settings WHERE value = "RecordChanged"
Everyday i collect about 30Mb of logs like this!!
How to ignore it? (I can't find any crontab refers to those...)

hi

Have you managed to fix your mysql log problem yet?

I saw your reply last week, and have been relucant to do a "me too" post, but I have been unable to track down a fix for this, and was wondering if you had.

Cheers

Gary

I didn't fix this problem... and i don't know where to obtain solutions...
Today, the log is 58Mb! After cron gunzip, it was 800kb...
And noone reply for any information about it...

My install was not a fresh install from the CD. As I already had a woring myth solution.

Once installed I restored my existing database, which was fine before I installed Knoppmyth.

I have checked all of the cron jobs, etc to no avail. I do not know where it's coming from.

I'll carry on looking, and if I find anything I'll post.

cheers

Gary

An update...

I was trawling through the mythtv mailing lists, and I've learnt that the recordchanged query seems to be a flag to prompt the backend to check for further changes i.e. scheduler changes etc. The

Why it is getting logged seems to be down to the options applied when the mysql deamon is started. There is a flag to prevent mysqld from logging all this, and there are also settings for caching queries in memory, which would avoid the disk activity I'm seeing.

I haven';t had a chance yet to play with the settings to try and eliminate the problem, but I at least know where to start now.

gary

this is controlled by the --log/-l (or possibly the --log-update) command line option when starting mysqld. its a good idea to keep a log of updates performed incase you need to roll back to a previous backup. i run mysqld on my master myth backend box and keep seperate logs (--log) and update logs (--log-update). the former logs very little info - mostly startup/shutdown stuff. the latter logs every sql statement that performs an update -- not queries. starting with mysql 4 (i think), a binary update log (--log-bin) is available -- not requiring as much storage space.

once per day, i run a backup:
mysqldump -F --opt -umythtv -ppassword mythconverg | gzip > /tmp/mysqldump.sql.gz ;
and send this and the 2 days worth of update logs to another box for storage. on a number of occassions, i've hosed my database (most recently with the switch to tv_grab_na_dd) and have been able to easily recover by feeding the latest backup to mysql (if mysqldump is run with the above options, it creates statements to drop tables, recreate them, and then insert the data) and then the update log up to the point of the problem.

my 2c,
rayc