古いデータを保持するmyismテーブル 'test'があります。ここでテーブルを再作成します。ストレージをmyismからinnodbに変更した以外はすべての列を同じにします。テーブルの再作成に使用したダンプされたSQLは次のようになります。
drop table test;
create table test ( ... )
engine=innodb
insert into test(...) values(...)
ここで「ストレージエンジンからのエラー-1が発生しました」というエラーが発生しました。ググったところ、ほとんどの結果は破損したinnodbテーブルに集中しています。私の場合、私はそれが壊れているとは思いませんが、それは私がドロップアンドクリエイトステートメントで見逃したものです。
もう1つは、上記のsqlを実行した後、テーブルテストに残されたのはfile.frmという名前のファイルだけです。
この問題を解決するにはどうすればよいですか?そして、私はおそらくこの種のより多くのタスクを実行する必要があります、myismテーブルを削除してinnodbテーブルとして再作成するための正しい手順は何ですか?
ありがとう。
OK。私は解決策を見つけました。この問題は、my.cnfのinnodb_force_recoveryパラメータによって引き起こされ、4に設定されていました。
この問題を解決するには、0に設定するか、my.cnfからこのパラメーターを完全に削除します
エラーログを確認すると、クエリ中に、mysqlは人間が読める言語で次のように書き込みます。innodbリカバリモードが有効になるまで、テーブルの内容を変更することはできません。正確に次のメッセージが表示されます。
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.
-1エラーの一般的な原因は、ディスクがいっぱいであることです。私はテスト目的でさまざまな小さなVMを使用しており、innodb
はそれらをいっぱいにし続けます(そして私はそれを忘れ続けます)。
$df -ah
100%でディスクが表示されている場合、それが-1
の原点です;)
AzureでSQLインポートを使用してこれを行い、変更する必要がありました
ENGINE = InnoDBを使用したENGINE = MyISAM
/etc/my.cnfに移動します
コメント行innodb_force_recovery = 1
ファイルを保存してmysqlを再起動します
UNIXまたはLinuxシステムのシステムエラーコードのエラーコードを見つけるには、errno.hを調べます。私のMacでは、次のことができます。
$ grep 28 /usr/include/sys/errno.h
#define ENOSPC 28/*デバイスにスペースが残っていません* /
Linuxなどの他のオペレーティングシステムでは、マシンレイヤーサブインクルードのため、他のレイヤーがいくつか存在します。しかし、これらのファイルを調べて、これらのエラー定義を見つけることができるはずです。
または、「man」コマンドを使用して、「intro」またはセクション「2」、オペレーティングシステムセクションの下にある他のマニュアルページを探します。