Robert Hall wrote:
>
> I have several databases that share a backup log file. The current log file
> hasn't been rotated or archived since last November. I'm trying to set up a
> regular automated backup and file rotation system. My problem is that I
> moved (mv command) the old mysql.log to mysql.log.old and created a new
> mysql.log, and now the system isn't doing backup logs. Looking at
> mysql.log.old, it looks like the system was doing backup logging right up to
> the point where I executed the mv command. Is there something I can check
> that tells me which file MySQL wants to use for backup logging, or is there
> some essential characteristic of backup log files that is missing from the
> new file I created with the cat command?
You need to read the manual .....
In there you will see that you have to tell mysql to restart its logging
via a mysql/bin/mysqladmin flush-logs.
mysql is probably still logging to the old file,l even thou you've
deleted it.
Within the source - is a logrotate mysql conf file for the redhat
logrotate app - I suggest looking at this. (if you used the rpm it may
be installed but not configured - or it may be present in the binary
release)
>
> This is a database that I inherited from a coworker who left. I'm expecting
> to be moved to another position soon, and I'm trying to get this database
> automated and documented so that the people who inherit it from me won't be
> as clueless or as helpless as I was. Also, I'd like to restore backup
> logging in case it's ever needed.
>
> One other mistake I made that might be related; I accidently deleted the
> .pid file. Uff da. (I'm a bit new to Unix.) I did ps -afux and got the pid
> number for the highest level process with the mysql name, and recreated the
> file. If I got the wrong pid number, would that effect backup logging?
>
> Red Hat Linux 6.1, Mysql 3.22.27, backup logging is on.
>
> Bob Hall
