日々の覚書

まずは慌てず騒がずエラーログを見る。クラッシュしてるログが出てるならそれはそれでOK。mysqld_safe とか systemd を使っている場合、 mysqld が自動再起動されているかも知れない。クラッシュリカバリーの真っ最中はプロセスが浮いていても接続できないので、クラッシュリカバリー中だったら見守る。

OOM Killerに殺された場合はエラーログに何も出ずにsyslogだけ吐くので、 /var/log/messages あたりもチラ見しておくと吉。

特にクラッシュはしていないようであれば、 dstat でCPU使用率やDisk書き込み、IOPSあたりを見る。

Disk書き込み量やIOPSがガリガリ増えているなら、datadirにでもいって ls -ltr とかで更新がされてるかどうか見る。バイナリーログやInnoDBログが更新されているなら、刺さっててもまだ何かしている（＝そのまま kill -9 でバッサリやると設定によってはファイルが壊れる）可能性がある。

設定によってはここでコアファイルをガリガリ書いている最中かも知れない。
その場合、ストレージ容量を食い破られないようにだけ注意（コアを吐き終わるまでmysqldが終了せず、コアは容量が足りなくて吐けず…でいつまでも終わらない）。
食い破られそうなら mysqld を kill -9 で仕留めるしかない。

Diskが何も書いてなさげでCPUだけ回っているならバッファプール周りで何か起こっていそうな予感。体感ではチェンジバッファとかページクリーナーがぐるぐるしていることが多い。 poor man’s profiler やPercona Toolkit化された pt-pmp で見てもいいけど、見たところで多分幸せにはならない（解決方法はわからないから）
ただこのケースは kill -9 でも壊れる可能性は低い（体感）、ただしMyISAMとMroonga、オメーは別だ。
解析のためにコアファイルを取りたければ ulimit -c とかabrtdの設定を確認してから kill -6 。容量には注意。見かけ上のサイズにVSZ、実容量でRSSを取る。

Diskにも書いてないしCPUも回っていないことがまれにだがよくある（特に5.7でデカめのインスタンスに mysqladmin shutdown を放り投げたあと…）が、その場合はなんか変なところで刺さっているんだろう…コア取ったりpt-pmpでスタックトレースを送り付けた方がいいかも知れない。

復旧（InnoDBのみ、安全なパラメーター、クラッシュリカバリーが成功していればプロセスを起動するだけでもいい）させたら今度は中身を見ていく。バックアップや他のスレーブからデータをコピーしてくる場合、エラーログをどこかに残しておかないと追うことも出来なくなるので注意。

基本はエラーログ。綺麗に（？）クラッシュしてる場合は “mysqld got signal x” のログがあるはず。これが無くていきなりプロセスが消えている場合はOOM Killerに殺された可能性が高い。

06:37:30 UTC - mysqld got signal 6 ;

Dive into MySQL Error - Speaker Deck でしゃべったけれど、 “signal 6” はアサーション（主にInnoDB）、 “signal 11” はバグな傾向がある。

“This could be because you hit a bug.” って書いてあるけどこれは単なるハードコード文なので真に受けてはいけない。

再起動しようとしてまた “signal 6” で落ちるなら、InnoDBのデータが破損している気がする。エラーログに含まれるスタックトレースの中にinnobaseな関数が並んでたりすると更に確率が上がる。

何度起動しようとしても “signal 11” で落ち 続ける ならデータが壊れている && そのエラーハンドルにバグがある予感。datadirをまるっとコピーしてバグレポートできると吉。

どっちのシグナルにしろ起動したら上がっちゃったなら、ハードウェアの一過性の障害という可能性もある。 dmesg やハードウェアのログも見るのを忘れずに。あとは mysqlcheck --all-databases とかしておくといいかも知れない。

……っていうのを某氏向けに書いていたんだけどすっかり時期を逸したので、ここでおとむらい。

​