LoginSignup
1

More than 5 years have passed since last update.

innodb_force_recoveryの値によってdumpが流し込めない

Posted at

はじめに

innodbを愛用するみなさんこんにちは。

dumpを流し込もうとすると以下のエラーで失敗しました。(バージョンはMariaDB 10.2.10です)

# zcat /var/db_dump/dump.sql.gz | mysql -u root
ERROR 1030 (HY000) at line 54: Got error -1 from storage engine

どうしたんだ困った子だね。

ログを見ると

InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.

どうしたんだ困った子だね。

新しいraw diskパーティションが作られたか、innodb_force_recoveryがonになっているよ。ユーザによってDB変更を許可していないよ。mysqldをshutdownしてmy.cnfのnewrawを変更して、innodb_force_recoveryオプションを取り除くんだ。

対処としてはinnodb_force_recovery=1が設定されてあったので0に書き直して再起動しました。dumpは流し込めました。

newrawとは

新しいRAWディスクパーティションのことだろう。

参考:14.5.8 共有テーブルスペースでの RAW ディスクパーティションの使用

データベースを作成するとき、データディレクトリに指定した場所にデータベース専用のディレクトリが作成されますが、このときにファイルシステムを介さずに書き込むための設定がRAWディスクパーティションのようです。

で、たぶんnewraw指定で作った場合ユーザ指定で作成はできないようです。ただ、今回はこの事象ではありませんでした。

innodb_force_recoveryとは

XtraDB/InnoDB Server System Variables - innodb_force_recovery

クラッシュ時のリカバリ挙動。デフォルトは0。値ごとの詳細は次。

XtraDB/InnoDB Recovery Modes

0はデフォルト。MariaDB10.2.7まではデータ変更可能な唯一のモードであった。10.2.7以降は3以下の値でトランザクションが可能となった。

1はクラッシュ時、REDOログをベースにリカバリを試みる。壊れてるテーブルはskipする。

2以降とだんだんレベルがあがってくる。4以上はデータは永続的に壊れる可能性があるので注意すること。

さて、なぜinnodb_force_recovery=1だとCREATE TABLEが実施できなかったのだろうか?

安全策として、innodb_force_recovery が 0 より大きい場合、InnoDB は INSERT、UPDATE、または DELETE 操作を回避します。MySQL 5.6.15 の時点では、4 以上の innodb_force_recovery 設定は InnoDB を読み取り専用モードにします。

そもそもおそらくクラッシュ時に一時的に1に設定したconfigを持ってきたのが悪かったですね。

(しかしおかしいな、なんで1の状態でしばらく動いていたんだろう。。。。)

おわりに

innodb_force_recoveryはinnodbがクラッシュしたときに1ずつあげて起動し、dumpをとろう。用が済んだらすぐ0に戻そう。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1