タグ: MySQL

ちょっとした理由でMySQLの大きめなテーブルにてインデックスが使えない状態となった。さて、そんな時、MySQLサーバのCPU使用率などはどんな傾向を示すのだろうか。…いや、わかりきっているんですけども

…というどっちでもいいことをGangliaのグラフから拾ってみた。一応、インデックスの復旧を頑張っていたので、使えていた状態から使えなくなる部分の差異は拾えなかったので、インデックスが効かない状態だったから、インデックスが有効になって使える状態に遷移した時のGangliaのグラフを。

まず、CPU使用率のグラフから。とある時点から、グラフの面積が明らかに小さくなっていると思うが、そこで、indexが復活している。

indexが効いていない間は、MySQLがCPUを使っているので、CPUのUserがぐーんと使われることになり、インデックスが効けば、きゅーんと下がる。

んで、当然のことながら、load averageはCPUの使用率に追随してくれる感じなので…。

15分のload averageは思ったよりもわかりやすく見えるなぁ…。これまた、わかりきったことではありますが、RDBMSにおかれましては、インデックスの存在は極めて重要だな、というわかりきったことが改めてわかった次第でございます。

手元に、MySQL向けのSQLの束があって、それを実行したいんだけど、一気に実行するとどーんとサーバに負荷がかかってしまうので、負荷を見ながら、こそこそと細かく実行していきたいなぁと。でも、1つのファイルのまま、MySQLのクライアントに渡してしまうと、もちろん一気に実行されてしまうので、例えば、SQLの束のファイルを分割することにより、複数回に分けて、MySQLクライアントに渡せばやろうとしていることが実現できそうってことで。

大きなファイルを分割するには、Linuxに搭載されていた「split」コマンドを使った。例えば、以下のような感じ。

split -l (分割したい行数) (分割したいファイル名) (prefix)

何個のファイルに分割されるかは、ファイルの行数次第なので確定はしないけれど、「(prefix)aa」から

始まって「(prefix)ab」…といった感じで連番のファイルに分割してもらえる。で、MySQLクライアントに「(prefix)aa」から実行していけばよさげ。

近々、買おうと思っていたら、第2版がでたらしいではないか。どうやら、前版では、MySQL4+MyISAMを前提にしていたけれど、第2版では、MySQL5+InnoDBを前提にした内容に書き換えられているらしい。まぁ、WebアプリだとMyISAMも登場する機会は少なくなさそうだけど、値段が値段だけど、買っといて損はないか…。

実践ハイパフォーマンスMySQL 第2版

posted with amazlet at 09.12.17

Baron Schwartz Peter Zaitsev Vadim Tkachenko Jeremy D. Zawodny Arjen Lentz Derek J. Balling
オライリージャパン
売り上げランキング: 11142

Amazon.co.jp で詳細を見る

NagiosでMySQLを監視してみたりしているが、これに関しては付属のプラグインを使って実現できた。じゃ、次にMySQLのレプリケーションがちゃんと動いているかどうかを監視しようとすると、Nagiosのサイトからダウンロードできるプラグインではちょっと難しそうだった。(確か、MySQLに対してクエリーを実行してくれるプラグインはあるんだけど、戻り値が数字じゃなきゃダメみたいな感じだったので…。)

そんなわけで、なんかないかなぁと思っていたら、Google CodeにPHPで書かれたNagiosプラグイン集があって、そのなかにMySQLのレプリケーションをチェックできそうな(…まだ見つけただけ)プラグインがあった。ちょっと試してみるか…と独り言。

なんかサーバが重いなぁと思って、show processlistで見てみると、MySQLが「unauthenticated user」で溢れていた。netstatで見てみても、MySQLのポートがこれまでにないくらいESTABLISHEDであふれかえっていて、結局、「unauthenticated user」からのアクセスが、コネクションを使い切って、…あー(涙)という状況になった。

とりあえず、何らかの対処をしないと困るので、とりあえず、MySQLを再起動してみたが、解決せず。さらに、Webサーバも再起動してみたし、OSも再起動してみたが、やっぱり解決せず。で、「unauthenticated user」でGoogle先生に聞いてみたところ、MySQLがアクセスしてくるクライアントのIPアドレスのDNSの逆引きをやっているらしく、逆引きができないときに「unauthenticated user」が溢れるという事象が起こるらしかった。

そこで、MySQLが動いているマシンの/etc/hostsファイルを編集して、アクセスしてくるマシンの名前解決ができるようにしたら、「unauthenticated user」にお引き取りいただくことに成功して、再び平和が訪れた。

しかし。「unauthenticated user」が溢れることになるトリガーがよくわからない。特にMySQL周辺の設定を変更したわけでもないのだが、突然、溢れ出したように見えた。

あと、MySQLがなんでDNSの逆引きをやってるかがわからないので調べてみた。MySQLの権限テーブルでアクセス元を制限できるけど、その制限の指定にホスト名が使える(…そういえば、localhostとか使ってるなぁ…)背景には、MySQLがアクセスしてきてるクライアントのIPを逆引きしているということがあるらしい。なるほどなぁ…。