Joel Fowler <[EMAIL PROTECTED]> writes:
> I've also reported this problem to Red Hat' Bugzilla as I understand
> they're responsible for the /etc/logrotate.d/mysql script. It's
> Bugzilla [Bug 51711] "Changed - MySQL looses bin-logs during
> logrotate".
3.23.41-1 uses a new method for flushing l
I've also reported this problem to Red Hat' Bugzilla as I understand
they're responsible for the /etc/logrotate.d/mysql script. It's Bugzilla
[Bug 51711] "Changed - MySQL looses bin-logs during logrotate".
Joel Fowler
===
At 01:16 PM 8/14/01 -0500
No, unfortunately they just seem to be gone along with the integrity of
most good recovery strategies.
Joel Fowler
==
At 01:16 PM 8/14/01 -0500, Gerald Clark wrote:
>I don't recall ever losing a log.
>Are you sure logrotate isn't renaming it?
>
>Joel Fowler wr
I don't recall ever losing a log.
Are you sure logrotate isn't renaming it?
Joel Fowler wrote:
> I agree that Red Hat has an issue with safe_mysqld and logrotate.
> However, in my opinion MySQL has a much more serious problem.
> In a logging system there shouldn't be any subtle ways to drop reco
I agree that Red Hat has an issue with safe_mysqld and logrotate.
However, in my opinion MySQL has a much more serious problem.
In a logging system there shouldn't be any subtle ways to drop records let
alone entire logs.
Kill -HUP is exactly that -- a very poor design leading to a
big trap - o
This really is not a MySQL issue, but a Red Hat issue.
Don't logrotate the MySQL bin logs.
Joel Fowler wrote:
> Environment: Red Hat 7.1
> mysqld 3.23.36-log
>
> /etc/my.cnf as follows:
>
> [mysqld]
> datadir=/var/lib/mysql
> socket=/var/lib/mysql/mysql.sock
Environment: Red Hat 7.1
mysqld 3.23.36-log
/etc/my.cnf as follows:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-bin=/bu/mysql/online-log/iServ2
log-bin-index=/bu/mysql/online-log/iServ2.index
[mysql.server]
user=mysql
basedir=/var/li
