はじめに
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。値ごとの詳細は次。
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に戻そう。