症状

MySQLで「InnoDB: Tablespace is corrupted」「Cannot load from mysql.proc」などのエラーが表示され、テーブルにアクセスできない

結論：まずこれを確認

  1. SHOW ENGINE INNODB STATUS\G でエラー詳細を確認
  2. エラーログ（/var/log/mysql/error.log）で破損箇所を特定
  3. バックアップの有無を確認してから復旧作業を開始

トラブルシューティングフロー

    flowchart TD
    A[テーブルスペース破損エラー] --> B{MySQLは起動している?}
    B -->|No| C[innodb_force_recovery で起動試行]
    B -->|Yes| D{エラーログを確認}
    D --> E{破損箇所は?}
    E -->|システムテーブル| F[mysql.proc等のシステム復旧]
    E -->|ユーザーテーブル| G[該当テーブルの復旧]
    E -->|ibdata1| H[全体復旧が必要]
    C --> I{起動した?}
    I -->|Yes| J[データをダンプ]
    I -->|No| K[recovery levelを上げて再試行]
    J --> L[再構築]

よくある原因

  • ディスク障害: 物理的なディスクエラーによるデータファイル破損
  • 電源断・強制終了: トランザクション途中での異常終了
  • ディスク容量不足: 書き込み途中でディスクフル発生
  • MySQLの異常終了: OOM Killerやプロセスkillによる中断
  • ファイルシステム破損: ext4/xfsなどのファイルシステムレベルの問題
  • バージョンアップ失敗: MySQL/MariaDBのアップグレード時の互換性問題
  • 手動でのファイル操作: .ibdファイルや.frmファイルの誤削除・移動

確認手順

ステップ1: エラーログを確認する

    sudo tail -100 /var/log/mysql/error.log
# または
sudo tail -100 /var/log/mysqld.log

🔍 チェックポイント: corrupted、cannot load、page checksum mismatch などのキーワードを探す

ステップ2: MySQLが起動しているか確認する

    sudo systemctl status mysql
# または
sudo systemctl status mysqld

🔍 チェックポイント: Active: active (running) なら起動中

ステップ3: InnoDBステータスを確認する

    mysql -u root -p -e "SHOW ENGINE INNODB STATUS\G" | head -100

🔍 チェックポイント: LATEST FOREIGN KEY ERROR や LATEST DETECTED DEADLOCK セクションにエラーがないか

ステップ4: 破損テーブルを特定する

    mysql -u root -p -e "CHECK TABLE データベース名.テーブル名;"

🔍 チェックポイント: Msg_text が OK 以外なら破損の可能性

ステップ5: バックアップの存在を確認する

    # mysqldumpバックアップの確認
ls -la /var/backup/mysql/

# バイナリログの確認
mysql -u root -p -e "SHOW BINARY LOGS;"

🔍 チェックポイント: 復旧に使えるバックアップがあるかを確認

ステップ6: innodb_force_recoveryで起動を試みる（MySQLが起動しない場合）

    # my.cnfに追記
sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf
# [mysqld]セクションに追加
# innodb_force_recovery = 1
  
    sudo systemctl restart mysql

🔍 チェックポイント: 起動しない場合は値を2→3→4→5→6と段階的に上げる（6が最大）

ステップ7: データをダンプする（起動できた場合）

    mysqldump -u root -p --all-databases --single-transaction > /tmp/all_databases_backup.sql

🔍 チェックポイント: エラーなくダンプが完了すればデータ救出成功

ステップ8: mysql.procが破損している場合の復旧

    # MySQLを停止
sudo systemctl stop mysql

# mysql.procテーブルを再作成
mysql -u root -p mysql < /usr/share/mysql/mysql_system_tables.sql

🔍 チェックポイント: ストアドプロシージャが失われる可能性があることに注意

NG行動（やってはいけないこと）

  • バックアップなしでファイルを削除する: 復旧不能になる可能性
  • innodb_force_recovery=6で運用を続ける: データ整合性が保証されない
  • 破損した.ibdファイルを手動でコピー・移動する: 状況が悪化する
  • 原因調査せずにMySQLを再インストールする: データが完全に失われる
  • ディスク障害を疑わずに復旧作業を進める: 根本原因が残ったまま再発する

よくある質問（FAQ）

Q1: innodb_force_recoveryの値はどう決める？

A: 1から順に試す。値が大きいほど多くのチェックをスキップするが、データ損失リスクも上がる。6でも起動しない場合はバックアップからの復旧が必要。

Q2: 特定のテーブルだけ破損している場合は？

A: ALTER TABLE テーブル名 ENGINE=InnoDB; でテーブル再構築を試みる。失敗する場合は該当テーブルをダンプして再作成する。

Q3: ibdata1が破損した場合の影響範囲は？

A: innodb_file_per_table=0（共有テーブルスペース）の場合、全InnoDBテーブルに影響。innodb_file_per_table=1の場合でも、システムテーブルスペースとして重要な情報を含むため、全体に影響が及ぶ可能性がある。

関連するエラー・症状

準備中

解決しない場合