私のmysql.general_logテーブルは大きくなりすぎていますか?
-
27-10-2019 - |
質問
私は最近、一般的なログをテーブルに保存する機能を活用するために、MySQL 5.1.6にアップグレードしました - > ie mysql.general_log。これを行うと、実際にシステムにヒットしているクエリの数にすぐに驚きました。この一般ログテーブルには、最初の1時間から約40,000行があります。一般的なログテーブルサイズの制限があるかどうかについて、MySQLドキュメントに書かれていることがわかりませんでした。
この一般的なログをこの速度で成長させるのに問題はありますか?
サイズの問題がある場合、それに対処する方法は?
サイズの問題がある場合、サイズの問題に対処する方法を受け入れたプラクティスはありますか?
テーブルをパージしてデータをファイルに保存するイベントを作成する必要がありますか?
助けてくれてありがとう!
解決
general_logテーブルはデフォルトでCSVエンジンを使用します。これは、文字通りドライブ上の本格的なCSVファイルですが、SQLを介してアクセスできます。これは、そのサイズ制限がファイルシステム上のファイルのサイズ制限であることを意味します。
他のヒント
私はログファイルのためにこのようなことをします。私は過去24時間を維持することにしか興味がありませんが、イベントを調整してアーカイブテーブルなどを作成することができます。イベントを実行するのに数秒間ログすることはありませんが、気にしません。
CREATE EVENT `prune_general_log` ON SCHEDULE
EVERY 1 DAY STARTS '2013-10-18'
ON COMPLETION NOT PRESERVE
ENABLE
COMMENT 'This will trim the general_log table to contain only the past 24 hours of logs.'
DO BEGIN
SET GLOBAL general_log = 'OFF';
RENAME TABLE mysql.general_log TO mysql.general_log2;
DELETE FROM mysql.general_log2 WHERE event_time <= NOW()-INTERVAL 24 HOUR;
OPTIMIZE TABLE general_log2;
RENAME TABLE mysql.general_log2 TO mysql.general_log;
SET GLOBAL general_log = 'ON';
END
のようなユーティリティを使用する必要があります mysql-log-rotate
http://dev.mysql.com/doc/refman/5.0/en/log-file-maintenance.html ログファイルの回転用。
これがベストプラクティスかどうかはわかりませんが、これは私の解決策でした。
DATE=$(date +"%Y%m%d%H%M")
mv general_log.CSV general_log.${DATE}.csv # move the log table file
sudo -u mysql -g mysql touch general_log.CSV # create a new log table file with correct owner and group
mysql -u root -e "FLUSH TABLE mysql.general_log" # flush the log table