155

私はMySQLにかなり慣れていないので、Googleやstackoverflow検索で助けが見つからないという非常に興味深いエラーが発生しています。

MacOS 10.8.3 で MySQL 5.6.10 のローカル サーバーを実行しており、MySQL の Navicat Essentials を介してデータベースを管理しています。

私が得たエラーは、データベースを数日/数週間正常に実行および管理した後、Navicat 内からクエリを使用して作成したテーブルの一部を削除する (不完全に見える) というものです。

これらのテーブルを使用してクエリを実行しようとすると、Navicat は特定のテーブルが存在しないことを警告します。これまでのところとても良いです-ここに良い部分があります：

以前そこにあった "temp" という名前のテーブルを作成しようとすると、次のエラー メッセージが表示されます。

Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.

ただし、テーブルを削除しようとするか、このテーブルのテーブルスペースを破棄しようとすると、

DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;

次のエラー メッセージが表示されます。

Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist

つまり、テーブル スペースを破棄するように勧められますが、破棄しようとするとテーブルが存在しません。DISCARD クエリがチェックしていない別の場所に、このテーブルのある種の残骸がある可能性はありますか? そして、完全にランダムに見えるように、何がそれらすべてを引き起こす可能性があるのか​​ 、誰か考えがありますか?

私が言ったように、私はこの主題に不慣れで、ほとんど無知です。ラップトップの再起動、つまりローカルの MySQL サーバーのリセット、またはユーザーのアクセス権が関係している可能性があると思われますが、ここでは仮説にすぎません。

4

27 に答える 27

145

ここで少し遅れましたが、一般的に、「innodb_file_per_table」モードで実行しているときに「テーブルスペースがいっぱいです」というエラーが発生したときに、この問題が発生するのを見てきました。あまり詳細には触れませんが (詳細はこちら)、データベース サーバーのテーブルスペースは innodb_data_file_path 設定によって定義され、デフォルトではかなり小さいです。大きくしても、「テーブルスペースがいっぱい」は、より大きなクエリなどで発生する可能性があります（テーブル以外の「もの」がそこに保存され、元に戻すログ、キャッシュなど...）。

とにかく、テーブルごとのファイルが保存されているOSディレクトリ、OSXではデフォルトで/var/lib/mysql、自作iircでは/usr/local/var/mysqlを調べると、通常のコンパニオン tablename.frm ファイルのない孤立した tablename.ibd ファイル。その .ibd ファイルを安全な一時的な場所 (念のため) に移動すると、問題が解決するはずです。

$ ls /var/lib/mysql

table1.frm
table1.idb
table2.frm
table2.idb
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb

$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/

ただし、1 つの注意点として、クエリの長​​時間実行、テーブルのロックなど、最初に問題を引き起こした原因が解消されていることを確認してください。そうしないと、2 回目の試行時に別の孤立した .ibd ファイルになってしまいます。

于 2014-02-11T02:47:48.957 に答える
86

Xampp および Mamp ユーザー

MySQL を介してデータベースを (空にした後) インポートするときに同じエラーが発生しました。tablename.ibd他のすべてのファイルが削除されている間にファイルが残っていることがわかりました。から手動で削除したところmysql/data/database_name、エラーはなくなりました。

于 2014-06-08T15:59:22.820 に答える
31

.idb削除した後に再度作成された場合は、この回答を読んでください。

これが私とどのように機能したかです。.idb対応していないファイルがあり、ファイル.frmを削除するたびに.idb、データベースがファイルを再作成します。そして、MySQLドキュメントの1行で解決策を見つけました（Tablespace Does Not Exist part ）

1- 一致する .frm ファイルを他のデータベース ディレクトリに作成し、孤立したテーブルが配置されているデータベース ディレクトリにコピーします。

2- 元のテーブルに対して DROP TABLE を発行します。これでテーブルが正常に削除され、InnoDB は .ibd ファイルが見つからないという警告をエラー ログに出力するはずです。

別のテーブル ファイルをコピーし.frmて、欠落しているテーブルのような名前を付けてから、通常のドロップ テーブル クエリを作成すると、うまくいき、テーブルが正常にドロップされます。

私のシステムは、Windows MariaDB v 10.1.8 の XAMPP です。

于 2016-09-23T02:30:37.557 に答える
24

WAMP [Windows 7 Ultimate x64 ビット] ユーザーの場合:

私は DangerDave の発言に同意するので、回答を WAMPユーザーに公開しています。

注:まず、..\WAMP\Bin\MySQL\MySQL[Your MySQL Version]\Dataフォルダーに移動する必要があります。

これで、すべてのデータベースのフォルダーが表示されます

  • 問題のあるテーブルがあるデータベースのフォルダーをダブルクリックして開きます
  • ファイルが存在するべきではなく、ファイル[Your offending MySQL table name].frmが存在する必要があります[Your offending MySQL table name].ibd
  • を削除します[Your offending MySQL table name].ibd
  • 次に、ごみ箱からも削除します
  • 次に、データベースで MySQL クエリを実行すれば完了です
于 2015-10-13T04:51:23.663 に答える
8

これは、ログファイルにまったく同じエラーを示したテーブルがあったときに、fedoraのmariadb 10.2.16で行ったこととまったく同じです...

2018-07-11  9:43:58 140323764213504 [Note] InnoDB: The file './database_name/innodb_table.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2018-07-11  9:44:29 140323764213504 [Warning] InnoDB: Tablespace 'database_name/innodb_table' exists in the cache with id 2836 != 2918

あなたの走行距離とエラーは異なる場合がありますが、私が想定する主なものは

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

テーブルの削除とテーブルの変更が機能しない...

MariaDB [database_name]> drop table innodb_table;
ERROR 1051 (42S02): Unknown table 'database_name.innodb_table'

MariaDB [database_name]> alter table innodb_table discard tablespace;
ERROR 1146 (42S02): Table 'database_name.innodb_table' doesn't exist

create table も次のように失敗します。

MariaDB [database_name]> create table  innodb_table(`id` int(10) unsigned NOT NULL);
ERROR 1813 (HY000): Tablespace for table '`database_name`.`innodb_table`' exists. Please DISCARD the tablespace before IMPORT

これを修正するために、私が最初にしたことは

create table  innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)

次に、/var/lib/mysql/database_name ディレクトリで、root として次のことを行い、innodb_table.ibd の上書きを確認して問題を引き起こしました

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

次に、mysqlコンソールに戻り、両方のテーブルでドロップコマンドを正常に発行しました

MariaDB [database_name]> drop table innodb_table;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    8
Current database: database_name

Query OK, 0 rows affected (0.08 sec)

MariaDB [database_name]> drop table innodb_table2;
Query OK, 0 rows affected (0.25 sec)

すべてが正方形になり、1 つのテーブルを再作成できます...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

編集：追加するつもりでした

restorecon -Rv /var/lib/mysql/database_name

データベースのコピー後にコマンドを実行して、すべての selinux コンテキストを本来あるべき方法で取得します。これは、データベースからそれらをほぼすぐに削除する場合でも、代わりに --archive または -a オプションを 2 つの cp に追加することもできます。コマンドなので、実際にはアーカイブオプションはこれを短縮します:

cp innodb_table2.frm innodb_table.frm
cp innodb_table2.ibd innodb_table.ibd
chown mysql:mysql innodb_table.frm innodb_table.ibd
chmod 660 innodb_table.frm innodb_table.ibd
restorecon -Rv /var/lib/mysql/database_name
systemctl restart mariadb

私がより良いと思う次のものだけに、すでに作成されたテーブルに設定されているselinuxコンテキストを保持します。

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

上記のコマンドの長いリストを、* でさらに短縮できる短いリストに置き換えました。

于 2018-07-11T15:18:14.963 に答える
3

解決

ただし、より簡単な方法は次のとおりです。MySQL を再起動してから、同じ 4 つの手順を次のように実行します。

1) created a dummy table in the database;
2) discarded its tablespace;
3) moved the .ibd file into the database folder on the system;
4) attached the tablespace back to the table

このようにして、データ ディクショナリとファイルのテーブルスペース ID が一致しました。したがって、テーブルスペースのインポートは成功しました。

これにより、リカバリ プロセス中やファイル転送中の InnoDB の「落とし穴」に対処する際の信頼性が高まります。

参照

于 2013-04-15T06:27:40.493 に答える
2

解決策の手順は次のとおりです。

  1. データベースをバックアップします（ドロップオプションとデータを含む構造）
  2. mysql エンジン サービスを停止します
  3. mysql/data 内から手動でデータベース ディレクトリを削除します。
  4. mysql エンジンを起動する
  5. 破損したデータベースとは異なる名前で新しいデータベースを作成します
  6. 新しいデータベース内に破損したテーブルの名前を持つ単一のテーブルを作成します (これがシークレットです)。まったく同じ構造でテーブルを作成することをお勧めします。
  7. データベースの名前を古い破損したデータベースに変更します
  8. バックアップを復元すると、テーブルは正常に機能します。
于 2015-11-17T17:31:44.543 に答える
0

テーブルスペースを削除しようとすると、他のエラーが発生する可能性があります。私にとっては、次のエラーが発生しました。

DROP TABLESPACE `tablename`

Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP'

私の解決策は、データベースを削除することでした。これにより、関連するすべてのテーブルスペースが削除され、テーブルを再度作成できるようになります。

于 2013-06-18T04:43:33.730 に答える
0

同じテーブルの適切なバージョンを持つ別のサーバーがある場合は、コピー (table_copy) を作成し、table_copy を問題のサーバーに転送します。次に、問題のテーブルを削除し、table_copy の名前を table に変更します。

于 2014-04-11T14:29:22.447 に答える
-2

この問題があり、エンジンを「myisam」などの他のエンジンに変更する別のオプションがない場合は、テーブルを作成してみてください。

免責事項： 別のストレージエンジンではサポートされない外部キー制約がある可能性があるため、これは有効な答えではありません。すべてのストレージ エンジンには、データの保存とアクセスに関する独自の専門性があり、これらの点も考慮に入れる必要があります。

于 2016-10-06T05:46:17.897 に答える
-2

MySQL データ ディレクトリを見つける必要がありました。

SHOW VARIABLES WHERE Variable_Name LIKE "%dir"

次に、そのデータベースを強制的に削除します。

sudo rm -rf

于 2018-11-13T04:03:09.177 に答える