MySQLが起動失敗による500エラーの解消

背景

ポートフォリオでMySQLを使用しているが、何故か自動で落ちてしまい500エラーがブラウザに表示されてしまう場合がある。

前提として、Nginx, Pumaの起動確認をするも問題なし。

対症療法

発生したエラー

ポートフォリオのURLにアクセスすると 500エラーが発生。

原因

本番環境のMySQLが起動失敗していた。
根本原因に対してはもっと下の「そもそもの根本改善」を御覧ください。

確認方法

sshでEC2インスタンスにログインしてから以下のコマンドでMySQLの確認

ターミナル

$ sudo service mysqld status

Redirecting to /XXXXX status mysqld.service
● mysqld.service - MySQL Server
   Loaded: loaded (/XXXXX/mysqld.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since 日時
（略）

Stopped MySQL Server.
XXXXXXXXXX: Starting MySQL Server...
XXXXXXXXXX: mysqld.service: main process ...E
XXXXXXXXXX: Failed to start MySQL Server.
XXXXXXXXXX: Unit mysqld.service entered f....
XXXXXXXXXX: mysqld.service failed.

Active: failedになっているとMySQLが死んでる状態。

ターミナル

$ sudo service mysqld start

MySQLを起動すると改善。

そもそもの根本改善

ググりまくっていると、MySQLのメモリとswap領域の記事が出てくる。

1. MySQLのメモリ消費

この問題の対応は、 table_definition_cacheの値を変更する。

これは「定義キャッシュに保管できるテーブル定義の数」を定義するものです。
最小400~最大2,000で設定可能です。

参考: MySQLドキュメント『table_definition_cache』

topコマンドでみると、以下のような感じで40%くらいメモリが消費されていた。

 PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 XXXX mysql     20   0 1389240 409792  30776 S  0.3 40.7   0:02.11 mysqld

MySQLにログイン

$ mysql -u root -p

以下のコマンドで設定の確認。
デフォルトなら2,000(最大)になっていると思います。

mysql> show variables like 'table_definition_cache';

値を以下のコマンドで変更しましょう。
変更後、show~コマンドで値が変更されていればOKです。

mysql> SET GLOBAL table_definition_cache=400;

変更後

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 XXXX mysql     20   0 1376992 389860  31404 S  0.3 38.7   0:03.24 mysqld

うーん、あんまり変わっていないような。。。いや、少しは改善、、したのか、、？
まあ、ポートフォリオなのでそんなにテーブル数ないし、とりあえずは意味があったと思う！

1. swap領域の確保

swap領域とは、使っていないメモリの内容を一時的に保管しておく場所です。
参考: 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

どうやらその他の記事的にこちらが原因のようです。

ec2インスタンスにログインし、freeコマンドで見てみましょう

[xxxx@xxxx ~]$ free
              total        used        free      shared  buff/cache   available
Mem:        1006892      671264       65920         680      269708      180784
Swap:             0           0           0

この通り、swap領域がないので、以下の記事を参考に設定しましょう。

AmazonAWSで、MySQL がよく落ちる？ そんな時はSWAP領域をチェック！

経過観察

1週間経過...MySQLが全く落ちなくなりました！

まとめ

【まずは以下を確認】

• error 500はWEBサーバー側の原因で引き起こされるもの
  -　ポートフォリオが急に落ちたらサーバー周り(WEB/アプリサーバー, DB)をチェックしよう
  -　Nginx, Puma, MySQLの起動ができているか確認しよう

【MySQLが原因の場合】

• メモリ消費を確認
• swap領域を確認

参考記事

• MySQL公式ドキュメント
• MySQLでtable_definition_cacheの値を変更する