mysqlの遅いクエリログエラーを修正するためのベストプラクティス13
Yumリポジトリを介してインストールされたCentOS5.5 MySQL 5.5
[エラー]ログに/var/log/mysqld.slow.logを使用できませんでした（エラー13）。 MySQLサーバープロセスの全期間にわたってログをオフにします。再度オンにするには：原因を修正し、MySQLサーバーをシャットダウンして再起動します。
MySQL 5.5の標準インストール（特にwebtaticリポジトリから）を使用すると、権限の問題により、遅いクエリログが実際に記録を開始できません。コピーを事前に作成し、それをuser：mysqlおよびgroup：mysqlに属するようにchownすると、正常に機能します。
まったく同じディレクトリ（/var/log）、mysql.logおよびmysql.error.logの作成とログ記録に問題はありません。
明らかに私はそれに対するハック的な修正を持っていますが、ハッカーを繰り返すためにlogrotateを追加する必要なしに、logrotateを使用できるようにしたいと思います。 （ハッカーよりも悪いのは、ハッカーを繰り返さなければならないことだけです。）
これを修正するためのベストプラクティスを知っている人はいますか？
Logrotateを使用してログファイルを移動してHUPを送信した後、mysqlプロセス（mysqld_safe、私は信じています）がログファイルを作成できないようです。私がここから離れている場合は、私に知らせてください。
私が遠く離れていないと仮定すると、ここにいくつかのオプションがあります：
- Mysqld_safeプロセスと同じユーザーが所有するディレクトリにログを移動します。たとえば、
/var/log/mysqld/ディレクトリを作成し、そこにログファイルを保存します。ディレクトリがmysql：mysql 700の場合、問題なく新しいファイルを作成できます。 - Move/SIGHUPメソッドの代わりにcopy/truncatelogrotateメソッドを使用します。 copy/truncateメソッドは、現在のログファイル（
mysqld.slow.log）を新しいファイル（mysqld.slow.log.1）にコピーしてから、元のファイルをゼロバイトに切り捨てます。これは、何らかの理由でログに書き込んでいるプロセスを中断したくない場合に役立ちます。もちろん、欠点は、元のファイルをゼロバイトにワイプして戻す前に、元のファイルを新しいファイルにコピーすると、ディスクのオーバーヘッドが増えることです。これは、そのファイルのlogrotateスタンザにcopytruncateオプションを追加し、不要になったpostrotateセクションを削除することによって行われます。
Logrotateのcreateオプションを使用して、古いログファイルをローテーションした後にログファイルを作成することもできます。その後に必要になるのは、mysqladminフラッシュログを呼び出すpostrotateスクリプトだけです（メンテナンスに使用するユーザー名/パスワードがある場合は、-uと-pを覚えておいてください）。これにより、オーバーヘッドを節約できます。ログファイルが大きくなった場合の複製。
ただし、作成またはコピートランケートのどちらの方法でもかまいません。スペースの要件を除けば、私は一方が他方よりも優れていることを知りません。