【AWS EC2】”データベース接続確立エラー”の原因切り分けと対処法について
この記事は最終更新から5年以上が経過しています。情報が古くなっている可能性があります。
こんにちは、しばです。
AWSのEC2でWordPressを構築したサイトで、これまでに何回か「データベース接続確立エラー」に遭遇しました。
対処法が数パターンに分かれたので、原因調査の方法と、それぞれの対処法についてまとめました。
AWS&ターミナル初心者の覚書きですが、困ってる方の参考になれば幸いです!
Contents
サーバーへssh接続を行う
キーペアの作成等はすでに済んでいて、プライベートキー(.pemファイル)が手元にあることが前提に書いています。
ターミナルを開き、以下のコマンドを打ちます。
$ ssh -i (プライベートキーのパス) ec2-user@(DNS名)
例)$ ssh -i /path/key.pem ec2-user@ec2-xxx-xxx-xxx-xxx.xx-xxx-x.compute.amazonaws.com
※ AWS EC2の場合、ユーザー名はec2-userで固定
必要に応じて管理者権限にしましょう。
$ sudo su -
原因の切り分け
メモリチェック
コマンド:$ free -tm
上記コマンドを打つと、使用メモリ量が確認できます。freeの値がかなり少ない場合はメモリ不足が原因である可能性が高いと考えられます。
例)メモリ不足でエラーだった時の値
total | used | free | shared | |
---|---|---|---|---|
Mem: | 7240 | 4473 | 2766 | 0 |
-/+ buffers/cache: | 679 | 6560 | … | |
Swap: | 0 | 0 | 0 | … |
Total: | 7240 | 4473 | 2766 | … |
空き容量チェック
コマンド:$ df -h
上記コマンドを打つと、使用ファイル容量が確認できます。Availが使用可能なファイルサイズなので、ここが少ない場合は容量不足が考えられます。
例)容量不足でエラーだった時の値
Filesystem | Size | Used | Avail | Use% | Mounted |
---|---|---|---|---|---|
/dev/xvda1 | 7.9G | 7.9G | 0 | 100% | … |
tmpfs | 3.6G | 0 | 3.6G | 0% | … |
* tmpfsは気にしなくてよさそうです
エラーログチェック
コマンド:$ less /var/log/myslqd.log
上記コマンドを打つと、エラーログの中身を見ることができます。(lessコマンドでファイルの中身をみる。Gと打てば最新情報が確認可能)
最初にチェックしてもいいし、これまでのコマンドで原因がわからなかったら確認してみましょう。
[Error]という文字列を探して、付近のメッセージをググるとおおよその原因がわかるかと思います。
例)容量不足が原因だった時のメッセージ(スペースが無いから書き込みに失敗したという内容)
190809 11:15:45 [ERROR] /usr/libexec/mysqld: Error writing file '/var/run/mysqld/mysqld.pid' (Errcode: 28)
190809 11:15:45 [ERROR] Can't start server: can't create PID file: No space left on device
対処方法
メモリ不足にしろ容量不足にしろ、根本的な対処は必要になると思います。
(プランをアップグレードしたり、一番の原因になるものを突き止めて解消したり)
とりあえず一時的に復旧させる対処法を書きます。
メモリ不足の場合
2つ方法があります。
内部的な挙動がどう違うのかわかっていませんが、私の場合はまずパターン1を試して、ダメだったらパターン2という形で解決することが多いです。
パターン1.データベース再起動
コマンド:$ sudo service mysqld start
パターン2.インスタンス再起動
AWS管理画面上から、インスタンス再起動を実施しましょう。
容量不足の場合
これは非常にシンプルですが、ログや過去のバックアップファイル等の不要ファイルや、容量を食っているファイルを削除します。
容量を多く使っている場所を突き止めるには以下のコマンドが使えます。
コマンド:$ sudo du -sh /*
これをやるとルートにあるファイル&フォルダの容量一覧が表示されるので、容量が大きいフォルダを見つけたらどんどん階層を下げていけば、どこが重くなっているのか確認することができます。
例)$ sudo du -sh /var/*
→$ sudo du -sh /var/www/*
→$ sudo du -sh /var/www/public/*
…
容量不足が解消されればサイトが復旧されましたが、なかなか復旧されなければ一旦データベースやインスタンス再起動をかけてあげてもいいかと思います。
最後に
AWS以外でssh接続をする機会はあんまりないんですが、原因の切り分けや、インスタンスの再起動以外の対処法はおそらくAWS EC2以外でも使えるものだと思います(´▽`)
サーバーなどわからん!と伝えていてもWeb系である以上ヘルプを求められることがちょくちょくあるので、原因調査系のコマンドは使いこなしたいなぁと感じてます。
ちなみにAWSで起きたエラー関連では、以前もFTPソフト・Cyberduckで「file system full」エラーが出た時の記事を書いています。
こちらもご参考にどうぞ!
Cyberduckでアップロードだけ失敗してしまう!原因と対処法について【file system full】
参考)
- https://qiita.com/aftercider/items/b04ffaf89132192475ff
- https://www.yamamanx.com/wprdpress-database-cantconnect/
- http://www.kaasan.info/archives/3973