waiting for table metadata lock でDBが死んだ

CopyContentDetectorで障害を起こしてしまったので、メモです。

■DBにアクセスできない

半年に一回、各テーブルのフラグメントを解消する目的で以下のSQLを実行しています。

ALTER TABLE 【テーブル名】 ENGINE INNODB;  

フラグメントを解消することで、ディスクの圧縮や速度低下の防止をすることが出来ます。今回はこのALTER TABLEをしているときにwaiting for table metadata lockが発生してDBが死にました。

mysql5.6では、上記ALTER TABLEはオンラインDDLなので、変更中もデータの取得・更新が出来るようになっています。しかし、何かが原因でトランザクションが長引いたり、トランザクション放ったらかしにすると、waiting for table metadata lockが発生してしまうみたいです。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 8.10.4 メタデータのロック

dev.mysql.com

トランザクション実行中がある→その間に別にalter tableで構造変更→他でトランザクション実行中だから待て。ロック発生→詰まって死ぬ

という感じでしょうか。どうも、alter tableの結果がcommitされる瞬間に発生する感じでした。

■今までは何で大丈夫だった？

単純にデータ量が少なかったためです。今までうまく行っていましたが、ずっとwaiting for table metadata lockが発生する危険を含んでいたのだと思います。それが、サーバの台数もかなり増えて同時接続・同時実行数がかなり多くなった、かつ処理するデータ量が多くなって発生する率上がって今回起こった。という感じだと思います。

このあたりを見ると、データ量少ないテーブルでも発生するときは発生するみたいですね。

サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだ - Qiita

ALTER TABLE実行する時は注意しましょう、、という事で。 ALTER TABLE ALTER TABLEすると以下のような挙動でカラム変更されるようです 他のセッションからのREADを許可し、WRITEをブロック 新...

qiita.com

■対応方法

いろいろあるようですが、waiting for table metadata lockが発生してしまうと、「サーバの再起動」か「止めているクエリをkillでやっつける」の二種類みたいですね。うーん。。。これ、今度からALTER TABLEの必要があるときは、結局メンテナンスモードにしないとだめですね。。