「何もしていないのにMySQLが壊れた」ときにとりあえずやること
※可愛いTシャツですが本題とはあまり関係ないですなぜか分からないが、
— ekotロボ (@ekot_ROBOT) June 19, 2017
システムエンジニアに好評だ!
ぱちょこん
<イラスト:店長 里一磨> https://t.co/mGkqPfgvtd
minne pic.twitter.com/dE8HHkVm7g
先日開発端末にインストールしていたMySQLが起動しなくなりました。ちょうどいい機会なのでそんなときどうするかをまとめました。 紹介する処置は簡単に行えるもので大して時間もかからないため、原因に心当たりがあろうがなかろうがすべて試してもいいです。
前提
一度は起動する環境をつくっていたが起動しなくなった。
筆者の環境
- OS: macOS Mojave ver 10.14.4
- shell: fish, version 3.0.2
- パッケージマネージャ: Homebrew
基本のエラーログ確認
最初に状況確認のためエラーログをみましょう。
tail -f /usr/local/var/mysql/[端末名].local.err
ログが十分に存在しない場合は、あえて正常に動作しない操作(mysql.server start
など)を行うのもありです。ログの内容によってはすぐに原因を特定することもできます。
よく見るメッセージの例を1つだけあげておきます。
> ERROR! The server quit without updating PID file /usr/local/var/mysql.
ログを見ても原因がわからない場合は後述する方法で1つずつ確認していきましょう。
なぜか生きているMySQLプロセスが存在する場合
すでに起動している(アクセスはできない)ためにMySQLが起動できないということがありえます。次のコマンドでプロセスを探しましょう。
ps aux | grep mysql
意図しないMySQLプロセスが見つかったときはkill
しましょう。
MySQLで使用予定のポートが空いていない場合
ポートが空いていなければMySQLは起動できません。次のコマンドで使用予定ポートの状況を確認しましょう。(MySQLのデフォルトポートは3306です。)
lsof -i :[ポート番号]
停止したはずのMySQLや他のプロセスが使用していた場合は停止(kill
)するか、起動するポートを変えるかしましょう。マイクロサービスなど、ポートを多く利用する人はそこそこの頻度で発生しそうです。
ソケットが残っている場合
特に指定なく使っている場合、MySQL用ソケットは1つしか作成できない(名前が重複する)ため、mysql.sock
やmysql.sock.lock
があると新たにMySQLは起動できません。次のコマンドで確認しましょう。
ls /tmp | grep mysql
意図しないソケットが残っていれば削除(rm
)しましょう。
これは再起動やPCのクラッシュなどでMySQLを正常に停止できなかったことが原因です。これはだれでもたまに発生するでしょう。
mysqlフォルダ内のファイルのownerやパーミッションがおかしい場合
MySQLは/usr/local/var/mysql
内にファイルを作ったり更新したりします。それらのパーミッションが適切に設定されていない場合、MySQLが起動しなかったり特定のタイミングで異常が発生します。パーミッションは次のコマンドで確認できます。
ls -al /usr/local/var/mysql/
私の環境ではデフォルトでownerがユーザ名(私の場合はnagamoto)、groupがadminでした。
基本的にはデフォルト値から変更する必要がないため、これが原因であることは少ないです。しかし、ググって見つけた方法を片っ端から試していると誤って変更してしまうかもしれません。*1chown
やchmod
は慎重に使いたいですし、エラーログにPermission denied
が含まれているときのみパーミッションを疑いましょう。
その他MySQLが壊れる原因
brew upgrade
でMySQLのバージョンをうっかり(または無意識に)上げてしまい、壊れてしまうことが多いようです。
バージョンアップはMySQL単体では動作しても他のシステムと組み合わせた時に不具合が出ることもあるので丁寧に行いましょう。
最後に
Dockerを使ったらこういう悩みは少なくなるので、ぜひ使いましょう!
*1:実際にchownを使用する検索結果はあった