mariadb
InnoDB

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

はじめに

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に戻そう。