※本記事は検証用サーバーで行った手順をもとに執筆しています。 本番環境で設定を変更する際は、必ずバックアップを取った上で実施してください。
先日、WordPress サイトにアクセスすると「データベース接続確立エラー」と表示され、MySQL が再起動を繰り返す事態が発生しました。
調査の結果、原因はメモリ不足であり、スワップ領域の追加と MySQL 設定の軽量化で解決しました。
本記事では、実際に行った手順と学びを記録します。
環境
| 項目 | 内容 |
|---|---|
| OS | Ubuntu 24.04 LTS |
| サーバータイプ | VPS（メモリ 1GB） |
| データベース | MySQL 8.0 系 |
| CMS | WordPress |
| 問題の症状 | 「データベース接続確立エラー」＋ MySQL の再起動ループ |
問題の概要
データベース接続エラー発生後 再起動すると一時的に動作するが、 しばらくすると再びデータベース接続エラーとなる。 以下のように、systemctl status mysql では繰り返し起動失敗を検出：
mysql.service: Main process exited, code=exited, status=1/FAILURE
mysql.service: Failed with result 'exit-code'.
また、sudo journalctl -u mysql.serviceでは以下のように MySQL が数秒おきに再起動を繰り返していることが確認できる
Nov 11 11:11:02 host_name systemd[1]: mysql.service: Scheduled restart job, restart counter is at 636.
Nov 11 11:11:02 host_name systemd[1]: Starting mysql.service - MySQL Community Server...
Nov 11 11:11:04 host_name systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE
Nov 11 11:11:04 host_name systemd[1]: mysql.service: Failed with result 'exit-code'.
Nov 11 11:11:04 host_name systemd[1]: Failed to start mysql.service - MySQL Community Server.
Nov 11 11:11:04 host_name systemd[1]: mysql.service: Scheduled restart job, restart counter is at 637.
Nov 11 11:11:05 host_name systemd[1]: Starting mysql.service - MySQL Community Server...
Nov 11 11:11:07 host_name systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE
調査内容
0. 問題の切り分け
WordPressのエラー表示がブラウザで確認できる
→ Ubuntu・Webサーバー・WordPressは正常に稼働している。
→ 再起動したらしばらくはサイト全体が正常に動くので認証はできている。
⇒ データベースが動作中にクラッシュしている
1. メモリ状況を確認
free -h
結果：
total used free shared buff/cache available
Mem: 961Mi 892Mi 58Mi 99Mi 253Mi 68Mi
Swap: 0B 0B 0B
2行目から、MySQLが起動していないにもかかわらず、892/961 MB を使い果たしていることが分かります。
3行目を見てみるとスワップ領域が存在せず、MySQLを起動すると物理メモリが枯渇することが分かりました。
解決策の概要
スワップ領域を追加し、MySQL のメモリ使用量を調整することで安定化。
スワップとは？
スワップとは、メモリが足りなくなったときにディスク上の一部を仮想的なメモリとして使う仕組みです。
物理メモリ（RAM）が1GBしかない環境では、MySQL や PHP が同時に動作するとすぐに足りなくなります。
スワップを設定しておくと、少なくとも「落ちずに耐える」ことができるようになります。
実際に行った解決手順
① 現在のメモリ状態を確認
どれだけ空きがあるかをチェック：
free -h
② 1GB のスワップファイルを作成
メモリ不足時に使われる仮想領域を作る：
sudo fallocate -l 1G /swapfile
③ アクセス権を変更
セキュリティのため root のみアクセス可能に：
sudo chmod 600 /swapfile
④ スワップ領域として初期化
作成したファイルをスワップ用に設定：
sudo mkswap /swapfile
⑤ スワップを有効化
すぐに利用可能にする：
sudo swapon /swapfile
⑥ スワップの状態を確認
有効になったか確認：
free -h
結果：
Swap: 1.0Gi 0B 1.0Gi
⑦ 永続化設定
再起動後もスワップが有効になるよう設定：
sudo nano /etc/fstab
/etc/fstabの末尾に以下を追記：
/swapfile none swap sw 0 0
⑧ MySQL のメモリ使用量を抑える設定
MySQL の設定を軽量化して安定動作を確保：
sudo nano /etc/mysql/conf.d/lowmem.cnf
以下のように編集・追記：
[mysqld]
innodb_buffer_pool_size = 128M
key_buffer_size = 8M
table_open_cache = 200
max_connections = 50
⑨ MySQL を再起動して反映
sudo systemctl restart mysql
正常に起動したことを確認：
sudo systemctl status mysql
結果
- MySQL が安定して起動するようになった
- WordPress の「データベース接続確立エラー」が解消
- メモリ使用率が安定し、再起動ループが消滅
学び
- 低メモリ環境では スワップ領域が生命線
- MySQL の起動失敗は「設定ミス」でなく「メモリ枯渇」であることも
- スワップ＋軽量設定で、1GB サーバーでも十分運用可能
まとめ
| 項目 | 内容 |
|---|---|
| 原因 | メモリ不足による MySQL 強制終了 |
| 対応 | スワップ 1GB 追加＋MySQL 設定軽量化 |
| 設定変更値 | innodb_buffer_pool_size=128M, key_buffer_size=8M, table_open_cache=200, max_connections=50 |
| 効果 | MySQL が安定して起動・稼働 |
| 学び | スワップを設定しない VPS は非常に不安定になる |
結論： 小容量VPSでは、「スワップを確保し、メモリ設定を見直す」 ことで MySQL を安定運用させることができます。 再起動で一時的に直っても、根本的な解決は“リソース管理”にあります。
コメント