MySQLのエラーが出続けて困った話

いつまでもトップ記事がオタク語りなのもなんなので、たまにはエンジニアっぽい備忘録でも。

ミドルウェアは、知らないとそもそも取っ掛かりが無くて調べることすらおぼつかないとこが多いから苦手だったりする。

特に僕なんかは英語苦手なので、日本語のドキュメントが少ないレアな奴だったりすると本当に死ねる。

そんなわけで週末にあったMySQLのトラブルのお話。

事象
なんだかDBサーバのIOが異常に上がってる！
よくよく見ると、MySQLのエラーログがガンガン肥大化して行ってる!!

ログの内容を確認してみると・・・
なんかの処理でデッドロックが発生したっぽい!!!

じゃあそのプロセス殺せばいいんじゃね？
と思ってshow processlist;してみても該当のはとっくに死んでそう

実は・・・
innodb_monitorとinnodb_lock_monitorなるエラーを記録しておくテーブルがあって、どうもこいつらがある限りガンガンエラーログが出力され続けるらしい↓
日々の覚書: InnoDB Monitorの仲間たち（InnoDBエンジン本体のアレ）
MySQL リファレンスマニュアル :: 7.5.10.1 SHOW INNODB STATUS と InnoDB モニタ

対策は
とりあえずエラー内容を確認したらちゃっちゃと上記２つをdrop tableすることでエラーログの出力は止まる。

便利機能なんだろうけど、知らなかったので焦った・・・

ーーーーー余談ーーーーー
前にハンターハンターの念能力をメタファーにしてエンジニアの技能について語っている記事があって面白いなぁとおもったのだけれども、実際僕みたいなアプリ寄りのエンジニアって「えいやっ！」とコード組んで作るのは好きでも、ミドルウェアを緻密に設定するのは苦手だったりすることが多いんじゃないかと思う。

しかしそうは言ってもミドルウェアによって最適解は変わるし、何より自力で作る際には否が応でも触る必要がでてくる。

そんなこんなで最近勉強しているのがchef↓

入門Chef Solo - Infrastructure as Code

Rubyやjsonのファイルとしてミドルウェアの構成を記述することで、コーディングをするようにサーバをセッティングできる。

というかここでもRubyが出てくるあたり、教養として押さえておかなきゃいけない言語な感すら出てきたな。