error log rotation problem

error log rotation problem

am 11.08.2011 21:30:07 von bmurphy

--000e0ce0b33c150d3f04aa3fd34c
Content-Type: text/plain; charset=ISO-8859-1

Hey everyone,

I have run across something that has me stumped. I have some systems that
have very large error logs because we haven't moved from statement-based to
mixed-based replication yet so they get a lot of warnings logged. I need to
rotate the error logs and have started looking at it doing so.

The problem is that on one system a normal course of action works perfectly,
but on anther it does not. And these systems were installed from the same
RPM packages (5.1.50 -- downloaded from the MySQL website).

Here is what I do:


log in with mysql client and 'flush logs' OR mysqladmin --flush-log

It should rename the old log file to mysqld.log-old and start a new
mysqld.log file.

On one system it works perfectly

On the other...nothing.

I tried moving the error log (mv /var/log/mysqld/mysqld.log
/var/log/mysqld.log.old) and then issuing the flush logs command...it stays
writing to the "old" file and never makes a new one.

If I were to restart mysqld it would solve the problem but this is a
production system and that isn't very practical.

These systems are very similar. my.cnfs have been checked for differences. I
searched the interwebs and specifically bugs.mysql.com for something
similar. Not finding anything.

I would appreciate any ideas!

thanks,

Keith

--000e0ce0b33c150d3f04aa3fd34c--

Re: error log rotation problem

am 12.08.2011 18:43:16 von Paul DuBois

On Aug 11, 2011, at 2:30 PM, Keith Murphy wrote:

> Hey everyone,
>=20
> I have run across something that has me stumped. I have some systems =
that
> have very large error logs because we haven't moved from =
statement-based to
> mixed-based replication yet so they get a lot of warnings logged. I =
need to
> rotate the error logs and have started looking at it doing so.
>=20
> The problem is that on one system a normal course of action works =
perfectly,
> but on anther it does not. And these systems were installed from the =
same
> RPM packages (5.1.50 -- downloaded from the MySQL website).
>=20
> Here is what I do:
>=20
>=20
> log in with mysql client and 'flush logs' OR mysqladmin --flush-log
>=20
> It should rename the old log file to mysqld.log-old and start a new
> mysqld.log file.
>=20
> On one system it works perfectly
>=20
> On the other...nothing.
>=20
> I tried moving the error log (mv /var/log/mysqld/mysqld.log
> /var/log/mysqld.log.old) and then issuing the flush logs command...it =
stays
> writing to the "old" file and never makes a new one.
>=20
> If I were to restart mysqld it would solve the problem but this is a
> production system and that isn't very practical.
>=20
> These systems are very similar. my.cnfs have been checked for =
differences. I
> searched the interwebs and specifically bugs.mysql.com for something
> similar. Not finding anything.
>=20
> I would appreciate any ideas!


There was a change to log flushing that affects the error log in =
5.1.51/5.5.7.
It might be the cause of what you're seeing.

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-7.html

"
Incompatible Change: Previously, if you flushed the logs using FLUSH =
LOGS or mysqladmin flush-logs andmysqld was writing the error log to a =
file (for example, if it was started with the --log-error option), it =
renamed the current log file with the suffix -old, then created a new =
empty log file. This had the problem that a second log-flushing =
operation thus caused the original error log file to be lost unless you =
saved it under a different name. For example, you could use the =
following commands to save the file:

shell> mysqladmin flush-logs

shell> mv host_name.err-old backup-directory

To avoid the preceding file-loss problem, renaming no longer occurs. The =
server merely closes and reopens the log file. To rename the file, you =
can do so manually before flushing. Then flushing the logs reopens a new =
file with the original file name. For example, you can rename the file =
and create a new one using the following commands:

shell> mv host_name.err host_name.err-old

shell> mysqladmin flush-logs

shell> mv host_name.err-old backup-directory

(Bug #29751)

See also Bug #56821.
"
--=20
Paul DuBois
Oracle Corporation / MySQL Documentation Team
Madison, Wisconsin, USA
www.mysql.com


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: error log rotation problem

am 12.08.2011 18:57:13 von prabhat kumar

--001517740ef41d914604aa51ceb7
Content-Type: text/plain; charset=ISO-8859-1

this will help you
http://adminlinux.blogspot.com/2009/09/mysql-log-file-rotati on.html

On Fri, Aug 12, 2011 at 9:43 AM, Paul DuBois wrote:

>
> On Aug 11, 2011, at 2:30 PM, Keith Murphy wrote:
>
> > Hey everyone,
> >
> > I have run across something that has me stumped. I have some systems that
> > have very large error logs because we haven't moved from statement-based
> to
> > mixed-based replication yet so they get a lot of warnings logged. I need
> to
> > rotate the error logs and have started looking at it doing so.
> >
> > The problem is that on one system a normal course of action works
> perfectly,
> > but on anther it does not. And these systems were installed from the same
> > RPM packages (5.1.50 -- downloaded from the MySQL website).
> >
> > Here is what I do:
> >
> >
> > log in with mysql client and 'flush logs' OR mysqladmin --flush-log
> >
> > It should rename the old log file to mysqld.log-old and start a new
> > mysqld.log file.
> >
> > On one system it works perfectly
> >
> > On the other...nothing.
> >
> > I tried moving the error log (mv /var/log/mysqld/mysqld.log
> > /var/log/mysqld.log.old) and then issuing the flush logs command...it
> stays
> > writing to the "old" file and never makes a new one.
> >
> > If I were to restart mysqld it would solve the problem but this is a
> > production system and that isn't very practical.
> >
> > These systems are very similar. my.cnfs have been checked for
> differences. I
> > searched the interwebs and specifically bugs.mysql.com for something
> > similar. Not finding anything.
> >
> > I would appreciate any ideas!
>
>
> There was a change to log flushing that affects the error log in 5.1.51/
> 5.5.7.
> It might be the cause of what you're seeing.
>
> http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html
> http://dev.mysql.com/doc/refman/5.5/en/news-5-5-7.html
>
> "
> Incompatible Change: Previously, if you flushed the logs using FLUSH LOGS
> or mysqladmin flush-logs andmysqld was writing the error log to a file (for
> example, if it was started with the --log-error option), it renamed the
> current log file with the suffix -old, then created a new empty log file.
> This had the problem that a second log-flushing operation thus caused the
> original error log file to be lost unless you saved it under a different
> name. For example, you could use the following commands to save the file:
>
> shell> mysqladmin flush-logs
>
> shell> mv host_name.err-old backup-directory
>
> To avoid the preceding file-loss problem, renaming no longer occurs. The
> server merely closes and reopens the log file. To rename the file, you can
> do so manually before flushing. Then flushing the logs reopens a new file
> with the original file name. For example, you can rename the file and create
> a new one using the following commands:
>
> shell> mv host_name.err host_name.err-old
>
> shell> mysqladmin flush-logs
>
> shell> mv host_name.err-old backup-directory
>
> (Bug #29751)
>
> See also Bug #56821.
> "
> --
> Paul DuBois
> Oracle Corporation / MySQL Documentation Team
> Madison, Wisconsin, USA
> www.mysql.com
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=aim.prabhat@gmail.com
>
>


--
Best Regards,

Prabhat Kumar
MySQL DBA

My Blog: http://adminlinux.blogspot.com
My LinkedIn: http://www.linkedin.com/in/profileprabhat

--001517740ef41d914604aa51ceb7--

Re: error log rotation problem

am 12.08.2011 19:25:16 von bmurphy

--001485f774f26725a504aa523217
Content-Type: text/plain; charset=ISO-8859-1

Hey everyone,

the problem was that I have the error log in /var/log/mysqld/mysql.error and
SELinux was not configured to allow it to rotate. I have compiled a custom
module to allow it so the problem is resolved. It was not an issue with
MySQL Server itself.

thanks again.

Keith

On Fri, Aug 12, 2011 at 12:57 PM, Prabhat Kumar wrote:

> this will help you
> http://adminlinux.blogspot.com/2009/09/mysql-log-file-rotati on.html
>
> On Fri, Aug 12, 2011 at 9:43 AM, Paul DuBois wrote:
>
>>
>> On Aug 11, 2011, at 2:30 PM, Keith Murphy wrote:
>>
>> > Hey everyone,
>> >
>> > I have run across something that has me stumped. I have some systems
>> that
>> > have very large error logs because we haven't moved from statement-based
>> to
>> > mixed-based replication yet so they get a lot of warnings logged. I need
>> to
>> > rotate the error logs and have started looking at it doing so.
>> >
>> > The problem is that on one system a normal course of action works
>> perfectly,
>> > but on anther it does not. And these systems were installed from the
>> same
>> > RPM packages (5.1.50 -- downloaded from the MySQL website).
>> >
>> > Here is what I do:
>> >
>> >
>> > log in with mysql client and 'flush logs' OR mysqladmin --flush-log
>> >
>> > It should rename the old log file to mysqld.log-old and start a new
>> > mysqld.log file.
>> >
>> > On one system it works perfectly
>> >
>> > On the other...nothing.
>> >
>> > I tried moving the error log (mv /var/log/mysqld/mysqld.log
>> > /var/log/mysqld.log.old) and then issuing the flush logs command...it
>> stays
>> > writing to the "old" file and never makes a new one.
>> >
>> > If I were to restart mysqld it would solve the problem but this is a
>> > production system and that isn't very practical.
>> >
>> > These systems are very similar. my.cnfs have been checked for
>> differences. I
>> > searched the interwebs and specifically bugs.mysql.com for something
>> > similar. Not finding anything.
>> >
>> > I would appreciate any ideas!
>>
>>
>> There was a change to log flushing that affects the error log in 5.1.51/
>> 5.5.7.
>> It might be the cause of what you're seeing.
>>
>> http://dev.mysql.com/doc/refman/5.1/en/news-5-1-51.html
>> http://dev.mysql.com/doc/refman/5.5/en/news-5-5-7.html
>>
>> "
>> Incompatible Change: Previously, if you flushed the logs using FLUSH LOGS
>> or mysqladmin flush-logs andmysqld was writing the error log to a file (for
>> example, if it was started with the --log-error option), it renamed the
>> current log file with the suffix -old, then created a new empty log file.
>> This had the problem that a second log-flushing operation thus caused the
>> original error log file to be lost unless you saved it under a different
>> name. For example, you could use the following commands to save the file:
>>
>> shell> mysqladmin flush-logs
>>
>> shell> mv host_name.err-old backup-directory
>>
>> To avoid the preceding file-loss problem, renaming no longer occurs. The
>> server merely closes and reopens the log file. To rename the file, you can
>> do so manually before flushing. Then flushing the logs reopens a new file
>> with the original file name. For example, you can rename the file and create
>> a new one using the following commands:
>>
>> shell> mv host_name.err host_name.err-old
>>
>> shell> mysqladmin flush-logs
>>
>> shell> mv host_name.err-old backup-directory
>>
>> (Bug #29751)
>>
>> See also Bug #56821.
>> "
>> --
>> Paul DuBois
>> Oracle Corporation / MySQL Documentation Team
>> Madison, Wisconsin, USA
>> www.mysql.com
>>
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe:
>> http://lists.mysql.com/mysql?unsub=aim.prabhat@gmail.com
>>
>>
>
>
> --
> Best Regards,
>
> Prabhat Kumar
> MySQL DBA
>
> My Blog: http://adminlinux.blogspot.com
> My LinkedIn: http://www.linkedin.com/in/profileprabhat
>



--

*
Paragon Consulting Services*

MySQL Operational Support, Systems Consulting and Training Services

* Coming in April our new online training course!!!

850-637-3877

--001485f774f26725a504aa523217--