・Amazon Lightsail で『データベース接続確立エラー』が突然表示されたんですが、、、
・『データベース接続確立エラー』の復旧方法が知りたい
・『データベース接続確立エラー』は頻繁に発生するので何とかしたい
・調査方法が知りたい
こういった疑問に答えます。
Amazon Lightsail で『データベース接続確立エラー』が突然表示された！調査方法と確認すべきポイントは？
Amazon Lightsailで突然『データベース接続確立エラー』が発生しました。
もちろん、この状態ではWordPressが表示されないので、即座に復旧作業が必要です。
今回は、こういった事象が発生した際の確認ポイントをご紹介したいと思います。
『データベース接続確立エラー』は、発生原因によって対応が異なる
『データベース接続確立エラー』はその名の通り、データベースへの接続が出来ないことで発生するエラーメッセージです。
つまり、ウェブサーバー（http、https）としては機能しているものの、何かしらの理由によりデータベースへアクセスが出来ない状態です。
この状態が発生する理由としては、
- データーベースのサービスが何かしらの理由で落ちている
- ハッキングなどにより、Amazon Lightsailのインスタンス自体が破壊されている
- データベース関連の設定に誤りがある
などでしょう。
データーベースのサービスが何かしらの理由で落ちている
今回、タクゾーの場合は結果的にこの事象でした。
何も設定などの変更を行っていない場合で突然『データベース接続確立エラー』の発生原因は、ほとんどの場合1か2のどちらかでしょう。
ただし、ログの調査の上で判断しましょう。
リブートして復旧するか確認する
「リブートして復旧するかどうか？」は、一つの重要な切り分けと作業となります。
ただし、ハッキングやランサムウェアなどの攻撃によるサーバーやサービスのダウンが発生した場合には、リブートはすべきはありません。
ハッキングやランサムウェアによる被害の場合には、リブートすることでサーバーが起動できないなど、調査に必要なログが取得できなくなる可能性があります。
暗号化されたファイルがある場合や、あるはずのディレクリやログがない場合には、ハッキングや ハッキングやランサムウェアなどの攻撃がなされている可能性があります。
また、リブートする場合には、必ずLightsail が正常に稼働していた際に取得したバックアップがあることを前提にリブートを行いましょう。
ログの確認方法
ログの確認方法と合わせて、「いつから事象が発生していたのか？」の確認しましょう。
『データベース接続確立エラー』 が発生している場合には、CPUなどの使用リソースにも変化があります。
その発生時刻のあたりを付けるには、メトリクスグラフの利用が有効です。
メトリクスグラフは、事象（トラブル）が発生しているインスタンスから確認ができます。
確認してみると、ある時間からCPU使用率に変化があったことが分かります。
グラフのログから、22時40分くらいに何かしらの変化があったことが分かります。
次に、この情報を元にログを確認します。
ログの調査の注意は、Amazon Lightsailのタイムゾーンは東京リージョンのインスタンスでもUTCで設定されていますので、タイムゾーンを変更していない場合には、ログの調査時にはUTCとJSTの時刻の変換が必要です。
bitnami@ip-address:~$ timedatectl
Local time: Sat 2021-09-18 02:37:31 UTC
Universal time: Sat 2021-09-18 02:37:31 UTC
RTC time: Sat 2021-09-18 02:37:31
Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
つまり、事象が発生している時間がログの時間ではないことを念頭にログの解析を行う必要があります。
さて、今回の場合は上記を元に確認すると、以下のログを確認することが出来ました。
bitnami@ip-address:~$ sudo cat /var/log/kern.log
Sep 17 13:42:42 ip-address kernel: [9613018.560157] Out of memory: Kill process 19100 (mysqld.bin) score 323 or sacrifice child
Sep 17 13:42:42 ip-address kernel: [9613018.566824] Killed process 19100 (mysqld.bin) total-vm:1220996kB, anon-rss:356916kB, file-rss:0kB
Sep 18 00:08:26 ip-address kernel: [ 0.000000] Initializing cgroup subsys cpuset
なお、/var/log/kern.logには、カーネルから出力されるメッセージ情報が格納されています。
syslogにも同様のメッセージが格納されていましたので、ログの調査としてはsyslogも同様に確認するのも良い手段の一つです。
bitnami@ip-address:~$ sudo cat /var/log/syslog
ログから、どうやらメモリーの空き容量が無くなったことが原因だと判明しました。
今後の対策の検討
Amazon Lightsail の最小インスタンスは、512MBとメモリーの容量に余裕が有るわけではありません。
コンテンツのアクセスが増えるとメモリーの使用量も自ずと増えていきます。
今回はしばらく様子をみてから対策の検討をしたいと思いますが、発生頻度によっては今後の対策が必要でしょう。
ここでいう対策とは、
- インスタンスをメモリ搭載量の多い物にアップグレードする
- メモリーを定期的にフラッシュ（開放する）
となります。
今回はリブート前にuptimeを確認したところ、100日以上は稼働していました。
コンテンツのアクセスが増えることで短期間に同じ事象が発生する可能性あります。
しばらく様子をみた上で、数か月に一度同様の事象が発生するようであれば、定期的にメモリーをフラッシュして様子を見たいと思います。
メモリーのフラッシュには、syncと合わせてechoコマンドを利用します。
bitnami@ip-address:~$ free -m
total used free shared buff/cache available
Mem: 486 284 5 58 196 97
Swap: 634 427 207
bitnami@ip-address:~$ sudo sh -c "sync && sync && sync && echo 3 > /proc/sys/vm/drop_caches"
bitnami@ip-address:~$ free -m
total used free shared buff/cache available
Mem: 486 285 55 59 146 96
Swap: 634 427 207
今回実行した”sync && echo 3 > /proc/sys/vm/drop_caches”については、man procに説明がありますので、興味がある方は説明を一読しましょう。
なお、procには以下の説明があります。
/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches, dentries, and inodes from memory, causing that memory to become free. This can be useful for memory management testing and performing reproducible filesystem benchmarks. Because writing to this file causes the benefits of caching to be lost, it can degrade overall system performance.To free pagecache, use:
引用元： Linux proc
echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes, use:
echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes,
use: echo 3 > /proc/sys/vm/drop_caches
Because writing to this file is a nondestructive operation and dirty objects are not freeable, the user should run sync(1) first.
実際コマンドを実行した直後は、一時的にfreeなメモリーが5MBから55MBに増えているのが分かります。
bitnami@ip-address:/var/log$ free -m total used free shared buff/cache available Mem: 486 286 7 58 191 95 Swap: 634 457 177ただし、数分後にfreeコマンドでメモリーの空き容量を確認すると、直ぐに7MBとなっていました。
常時SwapのUsedが0ではない（使われている）方が気になりますが、Ligsailの最小インスタンスだとこんなものなのでしょうか。。。
もし、メモリーのフラッシュを行っても直ぐに同事象が発生するようであれば、インスタンスのもう一つ上のプランにアップグレードしてメモリー搭載量を増やし、リソースに余裕を持たせる方が良いでしょう。
数か月おきに同事象が発生するようであれば、cronにechoコマンドを追加し定期的・強制的にメモリーがフラッシュされるように設定しましょう。
Amazon Lightsailでのcronの設定は以下が参考になりますので、ご確認ください。
ハッキングなどにより、Amazon Lightsailのインスタンス自体が破壊されている
最近は企業をターゲットとしたハッキングやランサムウェア被害のニュースを多く耳にします。
リブートしてサービスが起動しない場合で、且つ、3. の『データベース関連の設定に誤りがある』というような、何も作業を行っていない状況でインスタンスが復旧できない事象が発生している場合には、根本原因をしっかりと確認する必要があります。
この場合やらなければならない対策は3つで、
- サービスの復旧
- 根本原因の調査
- 今後の対策
で、1. の『データーベースのサービスが何かしらの理由で落ちている』場合と同じですが、対応内容が異なります。
【サービスの復旧】
まずはログやシステム状況を確認する必要がありますが、インスタンスが破壊されてしまっている場合には、今後の調査のためにその環境を保護しつつ、サービスの復旧を優先して対応する必要があります。
サービスの復旧はバックアップからのリカバリが最短ですが、バックアップがない場合には、一からシステムを構築し直す必要があります。
そうならないためにも、バックアップは定期的に取得するようにしましょう。
記事の投稿やシステムのアップデートなどのタイミングで必ずバックアップを取得がオススメ（というかMUST）です。
【根本原因の調査】
ハッキングやランサムウェアによる影響の場合には、データの流出が問題になることがあります。
個人のブログでは、データを抜かれて困る物があることはそこまで多くないはずですが、これが企業が運用するWordPressを利用したホームページの場合などの場合、情報の流出が二重脅迫ランサムウェアの被害となる場合があります。
個人のブログの場合には、基本的にはバックアップから復旧してサービス復旧で完了で良いでしょう。
あとででも根本原因の調査を行いたい場合は、被害にあった環境は保存しつつ新たなインスタンスを構築した上でバックアップデータからリカバリし、サービスの復旧を行いましょう。
【今後の対策】
ハッキングやランサムウェアが原因の場合には、環境にセキュリティホールが有った可能性があります。
具体的には、
- WordPressのアップデートを怠った
- WordPressの設定に誤りがあり、簡単にログインを許してしまう環境を放置した
- 様々な追加設定を行った結果、セキュリティに穴が開いてしまった
- Amazon Lightsailのコンソール自体が乗っ取られた
などでしょう。
バックアップからサービスの復旧を行うと同時に、セキュリティに穴がないかをしっかりを確認するようにしましょう。
そういった慣れていない場合には、専門家に相談するのも良いかもしれません。
このような状況でもバックアップさえあればコンテンツの復旧は可能なので、バックアップは頻繁に取得するようにしましょう。
また、Amazon Lightsailのコンソール自体が乗っ取り防止のためにもMFAの設定は必ず行うことをオススメします。
データベース関連の設定に誤りがある
以前、phpMyAdminによるバックアップ、リカバリの実施方法について以下で解説をしていますが、その際にも 『データベース接続確立エラー』 が発生します。
実際、WordPressの設定に誤りがあったため同様のエラーが発生しました。
今回のように、何も設定変更を行っていない場合に 『データベース接続確立エラー』 が発生した場合とは切り分け方法が異なります。
まとめ
今回は突然発生した 『データベース接続確立エラー』 についての対処、調査方法について纏めてみました。
今回は運良く直ぐに復旧することが出来ましたが、場合に寄っては調査や復旧作業が異なります。
もし、あなたが『データベース接続確立エラー』 が発生してしまった場合には、「いつから？何をした時？」などのイベントの有無を含めて調査する必要があります。
本ブログでは、ITエンジニアの小技をご紹介していますので参考になれば幸いです。
