とある豆腐のエラー考察（未完）

このエントリーは

• 学習記録：12月14日(金)：【MySQL8.0アップグレード】5.7.19->5.7.24->8.0.11 アップグレード手順【5.7.24 アップグレード後編-エラーを調べる】 - 叫ぶうさぎの悪ふざけ
• 学習記録：12月13日(木)：【MySQL8.0アップグレード】5.7.19->5.7.24->8.0.11 アップグレード手順【5.7.24 アップグレード前編】 - 叫ぶうさぎの悪ふざけ

に対する考察（？）エントリーです。

というわけでまずは まみー さんの↑のエントリーを読まれてからこのエントリーを読んでいただけると幸いです！

免責事項（？）ですが、俺はこのエラーの再現環境があるわけではないので、かなりの部分を推測に基づいて考察します。

---

時系列まとめ

1. MySQL 5.7.19を停止する
2. yum upgrade でMySQL 5.7.19 から MySQL 5.7.24にバイナリー入れ替え
3. (書かれていないけどMySQL 5.7.24の起動後) mysql_upgrade を実行（そしてこれが一部失敗している）
4. アクセスできないテーブルがあり、.ibdファイルが失われていることが判明

らしいです

mysql_upgrade のエラー

1, 2, 3と来る手順は間違っておらず、大概の場合ここで正常終了して「マイナーバージョンアップ完了、おつかれさまでしたー」となるはずが、 mysql_upgrade を実行したところエラーが出ている。

この結果で気になるところは2つ。

InnoDBのテーブルスペース（.ibdファイルまたはibdata1、設定依存）がない

mamy1326.c_log
Warning  : InnoDB: Tablespace is missing for table mamy1326/c_log.
Error    : Tablespace is missing for table `mamy1326`.`c_log`.
error    : Corrupt

mamy1326.t_session_log
Warning  : InnoDB: Tablespace is missing for table mamy1326/t_session_log.
Error    : Tablespace is missing for table `mamy1326`.`t_session_log`.
error    : Corrupt

読んで字のごとく、テーブルスペースがないらしい。

InnoDBはInnoDBのディクショナリーに「テーブル名とテーブルスペース（.ibdファイルまたはibdata1ファイル、場合によってはジェネラルテーブルスペースで名前が可変）」のマッピングを持っていて、それに従ってテーブルスペースを探しに行ったが見つからなかった、というエラー。

mysql_upgrade_infoが書き込めないエラー

Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' in the MySQL Servers datadir, errno: 13

mysql_upgrade は「最後に mysql_upgrade が実行されたバージョン番号」を datadir/mysql_upgrade_info というテキストファイルに書き出そうとする。それに失敗したよ、というエラー。

$ perror 13
OS error code  13:  Permission denied

/var/lib/mysql のパーミッションがおかしい、とまみーさんは踏んだようだが、

• mysql_upgrade_info は mysql_upgrade のプロセスが吐く、つまり mysql_upgradeコマンドを実行したOSユーザーの権限でファイルを作ろうとする
• Oracle提供のrpmファイルは /var/lib/mysql を mysqlユーザー、mysqlグループの751として作成するので、 mysql_upgrade コマンドを実行したOSユーザーが mysqlユーザーまたはrootユーザーでない限りは確かにファイルは作れずに転けるはず
  • https://github.com/mysql/mysql-server/blob/mysql-5.7.24/packaging/rpm-oel/mysql.spec.in#L1106
• mysql_upgrade は特にどのアカウントで実行したのか明記されていないけど、mysqlユーザーでやっていたのかどうかがカギになってくる
  • mamyユーザーみたいなOSユーザーでやっていた場合
    • 確かに権限がないので転けるのは自然
      • ちなみに、 mysql_upgrade の内部処理そのものをやるのは mysqld なので、 mysql_upgrade を実行したユーザーによらずアップグレード処理は正常に実施される（テーブルスペースが見つからないエラーは置いておく）
  • OSのmysqlユーザーでやっていた場合
    • 本来あるはずの書き込み権限がなかった…ということならば、どこかのタイミングでパーミッションが変更されていたはずで、 mysqld の実効ユーザーがdatadirに書けなくなったままプロセスが動いていたのならばちょっとくらいおかしくなってても別に不思議ではない…。

まずはここの切り分け。
前者ならばこれは単に「無視すればいい納得のいくエラー」であり、後者なら「InnoDBテーブルスペースを失う原因になりえる環境の異常」だ。

[ERROR] InnoDB: Cannot open datafile for read-only: './mamy1326/c_log.ibd' OS error: 71
[ERROR] InnoDB: Operating system error number 2 in a file operation.
[ERROR] InnoDB: The error means the system cannot find the path specified.

$ perror 71
OS error code  71:  Protocol error

$ perror 2
OS error code   2:  No such file or directory

VirtualBoxの共有フォルダのファイル開こうとしてEPROTO食らってる こともあるみたいで、 /var/lib/mysql の実態はVirtualBoxの.vdiとかの中にあったのか、ホストからマウントしていたのかがちょっと気になる。

後者の場合はパーミッションの事情がややこしくなりそう…。

どうでしょう？

​