MySQLのスローログは、通常それほど大量に出るものではないからか、自動でローテートされるような設定は特にない。しかし、負荷が上がったりしてスローログが大量に出てしまい、ローテートしたい場合はよくあるだろう。手動でローテートする場合は以下のように行う。
この例は、MySQLのデータディレクトリ(datadir)が /var/lib/mysql で、スローログファイル名(slow_query_log_file)がmysql-slow.logの場合。
$ cd /var/lib/mysql
$ mv mysql-slow.log mysql-slow.log.old
$ mysqladmin flush-logs
または
mysql> flush logs;
mysqladmin flush-logs あるいは flush logs で、ログファイルを開き直すことができる。
なお、5.1.12以降だとログ出力をコンソールからオフにできるので、オフにしてからflush-logsし、その後オンに戻すとよいだろう。
mysql> set global slow\_query\_log = 'OFF';
mysql> set global slow\_query\_log = 'ON';
ここで、MySQL5.1以前のバージョンでは「mysqladmin flush-logs」を実行すると、バイナリログや一般クエリログも全部まとめてローテートされてしまう。binlogを有効にしているサーバ(レプリケーションしている構成のマスタなど)では注意した方がいいかもしれない。
なお、5.5からは、
# スローログだけ開き直す
mysql> flush slow logs;
# 一般クエリログだけ開き直す
mysql> flush general logs;
# バイナリログだけローテート
mysql> flush binary logs;
# エラーログだけローテート
mysql> flush error logs;
というように、種類を指定できるようになっている。
(2014/12/17 エラーログについてコメントで指摘いただいたので追加。情報提供ありがとうございます)
ちなみにlogrotateで定期的にローテートする場合はこうやるそうだ。
| [MySQL の slowlog を logrotate する方法 |
Carpe Diem](http://www.sssg.org/blogs/naoya/archives/1251) |
定期的にローテートする必要があるほどスローログが出るままにするってのはどうかと思うが、そういうこともあるかもｗ
Cactiを使っていると、下の画像のように、ある一定の値以上をグラフに描画できない時がある。この例の場合、青い線であらわされたout-boundのトラフィックが80Mbpsを超えるとグラフが描画されていない。
このような場合は、以下を確認する。
トラフィックの場合、値を32ビットカウンタで取得していないか。
64ビットカウンタで値を取得しないと、桁あふれが起きてグラフが正常に描画されない。ホストの編集画面(Console → Devices → ホストをクリック)のAssociated Data Queriesで「SNMP - Interface Statistics 64bit only」を選ぶ。
そのグラフの扱える最大値を超えていないか。
グラフの編集画面(Console → Data Source → ホスト名 - 分類 - 項目(たとえば hogehoge-db01 - Traffic - eth0 のような)) のMaximum Valueの値が、小さく設定されているようなら、これを大きくしてみる。
RRDファイルに設定されている最大値を超えていないか。
RRDファイルにも各値の最大値が設定されている。これを無限大に設定してやる。以下は、上の画像のようにトラフィックが途切れる場合の対策の例。
$ rrdtool info hogehoge-db01\_traffic\_in_200.rrd
filename = "mwap-r10\_traffic\_in_200.rrd"
rrd_version = "0003"
step = 300
last_update = 1352714073
ds[traffic_in].type = "COUNTER"
ds[traffic\_in].minimal\_heartbeat = 600
ds[traffic_in].min = 0.0000000000e+00
ds[traffic_in].max = 1.0000000000e+07 ← ここが最大値
ds[traffic\_in].last\_ds = "3293068416"
ds[traffic_in].value = 1.2345678909e+08
ds[traffic\_in].unknown\_sec = 0
ds[traffic_out].type = "COUNTER"
ds[traffic\_out].minimal\_heartbeat = 600
ds[traffic_out].min = 0.0000000000e+00
ds[traffic_out].max = 1.0000000000e+07 ← ここが最大値
ds[traffic\_out].last\_ds = "2054038296"
ds[traffic_out].value = 1.2345678909e+08
ds[traffic\_out].unknown\_sec = 0
(後略)
rrdtool tuneコマンドで変更
$ sudo rrdtool tune hogehoge-db01\_traffic\_in\_200.rrd -a traffic\_in:U
$ sudo rrdtool tune hogehoge-db01\_traffic\_in\_200.rrd -a traffic\_out:U
$ rrdtool info hogehoge-db01\_traffic\_in_200.rrd
filename = "mwap-r10\_traffic\_in_200.rrd"
rrd_version = "0003"
step = 300
last_update = 1352714073
ds[traffic_in].type = "COUNTER"
ds[traffic\_in].minimal\_heartbeat = 600
ds[traffic_in].min = 0.0000000000e+00
ds[traffic_in].max = NaN ← 無限大に変わってる
ds[traffic\_in].last\_ds = "3293068416"
ds[traffic_in].value = 1.2345678909e+08
ds[traffic\_in].unknown\_sec = 0
ds[traffic_out].type = "COUNTER"
ds[traffic\_out].minimal\_heartbeat = 600
ds[traffic_out].min = 0.0000000000e+00
ds[traffic_out].max = NaN ← 無限大に変わってる
ds[traffic\_out].last\_ds = "2054038296"
ds[traffic_out].value = 1.2345678909e+08
ds[traffic\_out].unknown\_sec = 0
(後略)
Linuxが管理するキャッシュ領域には、バッファキャッシュとページキャッシュ領域があって、topコマンドや/proc/meminfoの「bufferes」「cached」という項目を見れば、現在のそれぞれのキャッシュ領域がどの程度なのかを確認することができる。
どちらも、ディスクの読み書きをキャッシュしてデータへのアクセスを高速化するという点では同じだが、それぞれがどのような意味で、どういう違いがあるのかについて、Quoraに分かりやすい解説があったので、翻訳してみた。
ページキャッシュは、ファイルI/Oを最適化するために、ファイルのページをキャッシュする。バッファキャッシュは、ブロックI/Oを最適化するために、ディスクブロックをキャッシュする。
Linuxカーネル2.4よりも前では、2つのキャッシュは明白に違うものだった。ファイルはページキャッシュに、ディスクブロックはバッファキャッシュに載せられていた。ほとんどのファイルがディスク上のファイルシステムによって扱われているとすると、データは2回、すなわち両方のキャッシュそれぞれに取り扱われる。多くのUnixシステムはこれと同じようなパターンを採用している。
これはシンプルな実装だが、明らかに洗練されていないし、非効率である。Linuxカーネル2.4からは、2つのキャッシュのコンテンツは統合された。VM(Virtual Memory)サブシステムがI/Oを司るようになり、それはページキャッシュからデータを取り出す。キャッシュされたデータがファイルとブロックの両方のかたちをとる(ほとんどのデータがそうだが)場合、バッファキャッシュは単純にページキャッシュを指し示す。つまり、データは1つだけがメモリにキャッシュされていることになる。ページキャッシュは、ディスクキャッシュのことを考えた通りのものだ。それは、後続のI/Oを高速化するために、ディスクからデータをキャッシュする。
バッファキャッシュはいまだに残っているが、それは、カーネルは現在もページ単位ではなくブロック単位のブロックI/Oを行う必要があるからだ。ほとんどのブロックはファイルデータのかたちを取っているため、バッファキャッシュの多くはページキャッシュと同等である。しかし、少量のブロックデータ、例えばメタデータやrawブロックI/Oなどは、ファイルを前提にしたものではなく、もっぱらバッファキャッシュによって取り扱われる。
現在のかたちに至った経緯まで含めて説明できるのは、経験豊かな人ならではというべきか。
