Help us understand the problem. What is going on with this article?

MySQLが突然の死を迎えた時の対処法

More than 5 years have passed since last update.

まえがき

これは、とあるウェブプログラマーがやらかした事件の手記である。

返事がない

ある日、Railsでmigrationを書いて、デプロイしたときに、ブラウザ氏からこう言われた。

502 Bad Gateway
nginx/1.4.3

_人人人人人人_
> 突然の死 <
 ̄Y^Y^Y^Y^Y ̄

まったくシャレにならないので、なんとかしよう。

原因を究明しよう

まず、原因を探ろう。

よくよく思い出してみると、マイグレーションが重すぎて途中停止してるっぽかった。その頃からアクセスが死んだようにも思える。
ということは、何かの拍子にDBをロックしてしまった可能性が高い。
ロック、聴くぶんには大好きだけどハメられるとすごく辛い。しかも死んでるし。

で、mysqlのprocesslistを確認する。原因となる作業プロセスがいるはずだ。

processlistの探り方

基本はUNIXのpsとかとだいたい同じ。アレのSQL版。

> show processlist;
| 284788 | tbaba | localhost:33573 | forkwell_dev | Sleep   |    1 |                                 | NULL                                                                                                 |
| 285029 | tbaba | localhost:37715 | forkwell_dev | Query   | 3595 | Waiting for table metadata lock | SELECT  DISTINCT `job_endorsements`.`id` AS t0_r0, `job_endorsements`.`job_id` AS t0_r1, `job_endors |
| 285342 | tbaba | localhost:43623 | forkwell_dev | Query   | 3654 | Waiting for table metadata lock | ALTER TABLE `users` DROP `facebook_identifier`                                                       |
| 285347 | tbaba | localhost:43685 | forkwell_dev | Query   | 3599 | Waiting for table metadata lock | SELECT `users`.* FROM `users`  WHERE `users`.`id` IN (9987, 5353, 8381, 9298, 8885, 9979, 519, 5805, |
| 285350 | tbaba | localhost:43717 | forkwell_dev | Query   | 3566 | Waiting for table metadata lock | SELECT  `users`.* FROM `users`  WHERE `users`.`id` = 298 LIMIT 1                                     |
| 285351 | tbaba | localhost:43725 | forkwell_dev | Query   | 3555 | Waiting for table metadata lock | SELECT  `users`.* FROM `users`  WHERE `users`.`id` = 9920 LIMIT 1                                    |
| 285352 | tbaba | localhost:43726 | forkwell_dev | Query   | 3558 | Waiting for table metadata lock | SELECT  `users`.* FROM `users`  WHERE `users`.`id` = 298 LIMIT 1                                     |
| 285353 | tbaba | localhost:43729 | forkwell_dev | Query   | 3555 | Waiting for table metadata lock | SELECT  `users`.* FROM `users`  WHERE `users`.`id` = 298 LIMIT 1                                     |
| 285354 | tbaba | localhost:43731 | forkwell_dev | Query   | 3553 | Waiting for table metadata lock | SELECT  `users`.* FROM `users`  WHERE `users`.`id` = 9545 LIMIT 1                                    |
| 285355 | tbaba | localhost:43736 | forkwell_dev | Query   | 3544 | Waiting for table metadata lock | SELECT  DISTINCT `job_endorsements`.`id` AS t0_r0, `job_endorsements`.`job_id` AS t0_r1, `job_endors |

2行目を見て欲しい。"Waiting for table metadata lock"と書いてある。
metadata lobkについてはここを見てもらうことにして、とにかくこいつらをどうにか動くようにしたい。
さっきUNIXのpsとだいたい同じ、と書いたが、まぁ消すときもだいたい同じだ。

> kill 284788
Query OK, 0 rows affected (0.00 sec)

で、消える。
こいつが原因だったらしく、こいつを消したらその他のロック解除待ちプロセスは一斉に解決されて、待ちプロセスはゼロになった。

あとがき

一番良いのはmetadata lockを引き起こさないようなコードを書くことだと思うので、ちゃんとトランザクションとかを意識して書けば良いと思う。
あと、ALTER TABLEには気をつけよう。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away