markdown

はじめに (対象読者・この記事でわかること)

この記事は、MX Linux をデスクトップまたは軽量サーバーとして利用しているシステム管理者・開発者向けです。特に、MySQL が「failed to start」や「Can't connect」などのエラーメッセージを出して起動しない状況に直面した方が対象です。この記事を読むことで、MySQL が起動しない原因を段階的に切り分ける方法、ログの見方、設定ファイルの典型的なミス、権限やディスク容量不足のチェック、そして最終的に正常に起動させる具体的な手順がわかります。筆者が実際に遭遇したトラブルとその解決策を交えて解説するので、同様の問題で時間を浪費することなく、迅速に復旧できるようになります。

前提知識

  • MX Linux の基本的なインストールとパッケージ管理（apt）ができること
  • MySQL（もしくは MariaDB）の基本的な概念と systemctl、service コマンドの使い方がわかること
  • ターミナルでテキストエディタ（nano、vim）が操作できること

MySQL が起動しない原因と背景

MX Linux は Debian 系ディストリビューションの派生で、軽量デスクトップ環境を提供します。デフォルトで mysql-server パッケージは提供されていないため、ユーザーは自分でインストールすることが多く、その過程で設定ミスや依存関係の不整合が生じやすいです。特に以下のようなケースが頻繁に報告されています。

  1. データディレクトリの権限不整合
    MySQL はデータディレクトリ（通常は /var/lib/mysql）への読み書き権限が mysql ユーザーに限定されています。権限が変わると起動時に致命的なエラーになります。

  2. 設定ファイル（my.cnf）の記述ミス
    文字コードやバインドアドレス、ポート番号の設定ミスは、サーバーの起動を阻害します。特に bind-address = 127.0.0.1 を外したまま外部から接続しようとすると、エラーが発生します。

  3. ディスク容量不足または InnoDB のリカバリ失敗
    ディスクがフルになると、InnoDB のリカバリプロセスが停止し、MySQL が起動しなくなります。/var/log/mysql/error.log に “InnoDB: Unable to allocate memory” 等のエラーメッセージが出力されます。

  4. パッケージ依存関係の破損
    apt-get install mysql-server 中に途中で中断したり、別のリポジトリから異なるバージョンをインストールした場合、依存関係が壊れ、systemctl start mysql が失敗します。

  5. MySQL のバージョンアップ時の設定変遷
    MySQL 5.7 から 8.0 にアップグレードした場合、デフォルトの認証プラグインが caching_sha2_password に変わります。古いクライアントやアプリが対応できず、起動時に警告が出てサーバーが停止することがあります。

これらの背景を踏まえて、実際に起動しない状態を診断する手順を順番に見ていきます。

MySQL が起動しないときの具体的なトラブルシューティング手順

以下では、典型的なトラブルシナリオごとに、コマンド例とともにチェックポイントを示します。まずは 全体像の把握、次に 個別要因の検証、最後に 復旧手順 の順で進めます。

ステップ1　サービス状態と基本エラーログの確認

Bash

# サービスの状態を取得
systemctl status mysql.service

# エラーログの直近10行を表示
journalctl -u mysql.service -n 10 --no-pager

# MySQL 固有のエラーログ（デフォルトは /var/log/mysql/error.log）
sudo tail -n 30 /var/log/mysql/error.log
  • systemctl status が failed と表示されたら、失敗原因が Active: failed の下に出ます。
  • journalctl と error.log の両方を確認することで、カーネルレベルのエラーと MySQL アプリケーション側のエラーの両方を把握できます。

よくあるメッセージ例
- Can't start server: can't create PID file: Permission denied → 権限問題
- InnoDB: Fatal error: cannot allocate memory for the buffer pool → メモリ/ディスク不足
- Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist → データベース破損

ステップ2　データディレクトリと権限の検証

Bash

# ディレクトリ所有者と権限を確認
ls -ld /var/lib/mysql
ls -l /var/lib/mysql

# 権限が正しくない場合は修正
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql
  • MySQL が起動できるのは、ディレクトリが mysql ユーザーに所有され、かつ 750 以上の権限が付与されている必要があります。
  • 権限が緩すぎるとセキュリティ上の警告が出るだけでなく、起動時に「Permission denied」エラーとなります。

ステップ3　設定ファイル（my.cnf）の整合性チェック

Bash

# 設定ファイルの場所確認
sudo grep -R "datadir" /etc/mysql/
sudo cat /etc/mysql/my.cnf

# syntax エラーがないか検証
sudo mysqld --verbose --help | grep -A5 "Default options"
  • my.cnf に不正な行が混入していると、MySQL は起動時にパースエラーを出します。
  • 特に skip-networking や skip-grant-tables が意図せず有効化されていないか確認してください。

典型的な修正例 

Ini

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
bind-address    = 127.0.0.1

ステップ4　ディスク容量とメモリの確保

Bash

# ディスク使用量を確認
df -h /var/lib/mysql

# メモリとスワップの使用状況
free -h
  • ディスクが 95% 以上埋まっていると InnoDB のログ書き込みができず、起動に失敗します。不要なログやバックアップを削除して空き領域を作ります。
  • メモリ不足の場合は、innodb_buffer_pool_size を一時的に小さくして再起動を試みます。設定は my.cnf に追加可能です。 
Ini

innodb_buffer_pool_size = 256M   # 2GB 以上のシステムでは 256M でも可

ステップ5　パッケージ依存関係とバージョンの整合性確認

Bash

# パッケージの状態を確認
dpkg -l | grep mysql

# 依存関係が破損している場合は修復
sudo apt-get update
sudo apt-get -f install
sudo apt-get reinstall mysql-server
  • apt-get -f install は依存関係の欠損を自動的に修正します。
  • 再インストール時に dpkg-reconfigure mysql-server を実行すると、データディレクトリや root パスワードの再設定ができます。

ステップ6　起動テストと自動起動設定

Bash

# 手動で起動
sudo systemctl start mysql

# 起動確認
sudo systemctl status mysql

# 起動失敗時は再度ログ確認
sudo journalctl -u mysql -p err -n 20

# 自動起動を有効化
sudo systemctl enable mysql
  • 手動起動でエラーが出なければ、次にシステム起動時に自動で立ち上がるかを確認します。
  • systemctl enable が失敗した場合は、/etc/systemd/system/multi-user.target.wants/ 配下のシンボリックリンクが正しく作成されているか確認してください。

ハマった点やエラー解決

ケース1　mysqld: Permission denied が継続的に出る

  • 原因: /var/run/mysqld ディレクトリが削除され、再起動時に自動作成されない。
  • 解決策: 手動でディレクトリを作成し、所有者を mysql に設定。
Bash

sudo mkdir -p /var/run/mysqld
sudo chown mysql:mysql /var/run/mysqld
sudo systemctl restart mysql

ケース2　InnoDB: Unable to lock ./ibdata1, error: 11（ロック競合）

  • 原因: 前回の MySQL プロセスが異常終了し、ロックファイルが残存。
  • 解決策: ロックファイルを削除し、プロセスが残っていないか確認。
Bash

sudo lsof | grep ibdata1   # 残存プロセスが無ければ
sudo rm -f /var/lib/mysql/ibdata1.lock
sudo systemctl start mysql

ケース3　caching_sha2_password が原因で起動直後にエラー

  • 原因: MySQL 8.0 でデフォルト認証プラグインが変わり、古いクライアントが接続できない。
  • 解決策: my.cnf に以下を追記し、従来の mysql_native_password に戻す。
Ini

[mysqld]
default_authentication_plugin=mysql_native_password

その後、systemctl restart mysql で再起動。

完全復旧までのフローまとめ

  1. サービスとログの状態確認 → 原因ヒント取得
  2. 権限・所有者の検証 → Permission denied 系エラー除去
  3. 設定ファイルの構文チェック → mysqld のパースエラー解消
  4. ディスク・メモリの確保 → InnoDB リカバリ失敗回避
  5. パッケージ依存の再インストール → 壊れた依存関係を修復
  6. 手動起動テスト → 正常起動確認 → 自動起動設定

この手順を順に実施すれば、ほとんどの「MySQL が起動しない」ケースを自己解決できるはずです。

まとめ

本記事では、MX Linux 環境で MySQL が起動しない典型的な原因と、その原因を段階的に切り分ける診断フロー、そして最終的にサーバーを再起動させる具体的な手順を詳述しました。

  • 原因特定：systemctl と journalctl でエラーログ取得 → 権限・設定・ディスク不足を中心にチェック
  • 対処法：権限修正、my.cnf の見直し、ディスク空き容量確保、パッケージの再インストール
  • 復旧手順：手動起動 → 自動起動設定までのフルプロセス

この記事を通じて、読者は「MySQL が起動しない」問題を自力で診断・解決できるスキルを身につけられます。次回は、MySQL のパフォーマンスチューニングやバックアップ戦略に焦点を当てた記事を予定しています。ぜひご期待ください。

参考資料