web-dev-qa-db-ja.com

エラーテーブルが見つからないか、開けませんか?

  • MySQLバージョン:5.5.24

次の問題のため:

mysql> desc reportingdb.v3_zone_date_cpm7k;       
ERROR 1146 (42S02): Table 'reportingdb.v3_zone_date_cpm7k' doesn't exist

/ var/log/mysqld.log

120927 16:57:04 [ERROR] Cannot find or open table reportingdb/v3_zone_date_cpm7k#P#pcurrent_2012926 from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
how you can resolve the problem.

(まだ理由がわかりません)

テーブルのファイルはまだdatadirにあります:

-rw-rw---- 1 mysql mysql    8932 Sep 26 16:50 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k.frm
-rw-rw---- 1 mysql mysql      84 Sep 26 16:50 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k.par
-rw-rw---- 1 mysql mysql 9437184 Sep 13 17:56 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#MERGER_2012828.ibd
-rw-rw---- 1 mysql mysql 1048576 Sep 27 15:42 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#MERGER_2012926.ibd

これは1か月前のバックアップからのテーブルDDL(パーティションが変更されたため)ですが、参照用です。

CREATE TABLE `v3_zone_date_cpm7k` ( 
 `campaignid` mediumint(9) NOT NULL DEFAULT '0' COMMENT 'sub_campaignid', 
 `zoneid` smallint(6) NOT NULL DEFAULT '0', 
 `bannerid` mediumint(9) NOT NULL DEFAULT '0', 
 `totalclick` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `realclick` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `clickcharge` mediumint(9) NOT NULL DEFAULT '0', 
 `totalview` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `viewcharge` mediumint(9) unsigned NOT NULL DEFAULT '0', 
 `dt` date NOT NULL DEFAULT '0000-00-00', 
 `partnerid` smallint(6) unsigned NOT NULL DEFAULT '0', 
 KEY `ix_zoneid` (`zoneid`,`dt`), 
 KEY `ix_dt` (`dt`), 
 KEY `ix_campaignid` (`bannerid`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 
/*!50100 PARTITION BY RANGE (TO_DAYS(dt)) 
(PARTITION p00 VALUES LESS THAN (0) ENGINE = InnoDB, 
PARTITION p04 VALUES LESS THAN (734965) ENGINE = InnoDB, 
PARTITION p05 VALUES LESS THAN (735025) ENGINE = InnoDB, 
PARTITION MERGER_2012822 VALUES LESS THAN (735102) ENGINE = InnoDB, 
PARTITION pcurrent_2012822 VALUES LESS THAN (735103) ENGINE = InnoDB, 
PARTITION pcurrent_2012823 VALUES LESS THAN (735104) ENGINE = InnoDB)*/

this のガイドに従って、このテーブルを回復します。しかし2cで。ステップ、私は以下のエラーが発生します:

mysql> alter table v3_zone_date_cpm7k_restore discard tablespace;
ERROR 1031 (HY000): Table storage engine for 'v3_zone_date_cpm7k_restore' doesn't have this option

http://bugs.mysql.com/bug.php?id=52422

私は今何ができますか?


[〜#〜]更新[〜#〜]

バックアップから復元していますが、この問題を取り除くための正しい手順は何ですか?

私が試したもの(別のサーバーで):

  1. DROP TABLE->それでも「存在しない」を取得する

  2. MySQLを停止する

    • テーブルのすべてのファイルを別の場所に移動します

    • バックアップファイルを対応するデータベースにコピーする

    • MySQLを起動します。


    120927 19:12:07  InnoDB: Error: table 'reportingdb/v3_zone_date_cpm7k#P#MERGER_2012828'
    InnoDB: in InnoDB data dictionary has tablespace id 741528,
    InnoDB: but tablespace with that id or name does not exist. Have
    InnoDB: you deleted or moved .ibd files?
    InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
    InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
    InnoDB: table still exists in the InnoDB internal data dictionary.
    InnoDB: Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
    InnoDB: for how to resolve the issue.
    InnoDB: We removed now the InnoDB internal data dictionary entry
    InnoDB: of table `reportingdb`.`v3_zone_date_cpm7k` /* Partition `MERGER_2012828` */.
    120927 19:12:07  InnoDB: error: space object of table 'reportingdb/v3_zone_date_cpm7k#P#MERGER_2012926',
    InnoDB: space id 921829 did not exist in memory. Retrying an open.
    120927 19:12:07  InnoDB: Error: table `reportingdb`.`v3_zone_date_cpm7k` /* Partition `pcurrent_2012926`
*/ does not exist in
     the InnoDB internal
    InnoDB: data dictionary though MySQL is trying to drop it.
    InnoDB: Have you copied the .frm file of the table to the
    InnoDB: MySQL database directory from another database?
    InnoDB: You can look for further help from
    InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html

UPDATE金曜日9月28日08:21:49 ICT 2012

あなたの提案に従ってください、私は持っています:

  • mySQLを停止しました
  • v3_zone_date_cpm7k *を別の場所に移動
  • mySQLを開始
  • .sqlファイルをインポートしてエラーが発生しました:

    25行目のエラー1050(42S01):テーブル 'reportingdb.v3_zone_date_cpm7k/*パーティションp00 */' もう存在している

エラーログは以下を示します:

120928  8:26:42  InnoDB: Warning: trying to init to the tablespace memory cache
InnoDB: a tablespace 932889 of name './reportingdb/v3_zone_date_cpm7k#P#p00.ibd',
InnoDB: but a tablespace 932783 of the same name
InnoDB: already exists in the tablespace memory cache!
InnoDB: We assume that InnoDB did a crash recovery, and you had
InnoDB: an .ibd file for which the table did not exist in the
InnoDB: InnoDB internal data dictionary in the ibdata files.
InnoDB: We assume that you later removed the .ibd and .frm files,
InnoDB: and are now trying to recreate the table. We now remove the
InnoDB: conflicting tablespace object from the memory cache and try
InnoDB: the init again.

そしてその .idbファイルは再起動後に自動的に作成されます:

# ls -l /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#p00.ibd 
-rw-rw---- 1 mysql mysql 65536 Sep 28 08:35 /var/lib/mysql/reportingdb/v3_zone_date_cpm7k#P#p00.ibd
5
quanta

mysql>プロンプトから次のコマンドを実行して問題を解決しました:

CREATE TABLE `v3_zone_date_cpm7k` (
  `campaignid` mediumint(9) NOT NULL DEFAULT '0' COMMENT 'sub_campaignid',
  `zoneid` smallint(6) NOT NULL DEFAULT '0',
  `bannerid` mediumint(9) NOT NULL DEFAULT '0',
  `totalclick` mediumint(9) unsigned NOT NULL DEFAULT '0',
  `realclick` mediumint(9) unsigned NOT NULL DEFAULT '0',
  `clickcharge` mediumint(9) NOT NULL DEFAULT '0',
  `totalview` mediumint(9) unsigned NOT NULL DEFAULT '0',
  `viewcharge` mediumint(9) unsigned NOT NULL DEFAULT '0',
  `dt` date NOT NULL DEFAULT '0000-00-00',
  `partnerid` smallint(6) unsigned NOT NULL DEFAULT '0',
  KEY `ix_zoneid` (`zoneid`,`dt`),
  KEY `ix_dt` (`dt`),
  KEY `ix_campaignid` (`bannerid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

次に、.sqlファイルでコメント化します。

-- DROP TABLE IF EXISTS `v3_zone_date_cpm7k`;
-- /*!40101 SET @saved_cs_client     = @@character_set_client */;
-- /*!40101 SET character_set_client = utf8 */;
-- CREATE TABLE `v3_zone_date_cpm7k` (
--   `campaignid` mediumint(9) NOT NULL DEFAULT '0' COMMENT 'sub_campaignid',
--   `zoneid` smallint(6) NOT NULL DEFAULT '0',
--   `bannerid` mediumint(9) NOT NULL DEFAULT '0',
--   `totalclick` mediumint(9) unsigned NOT NULL DEFAULT '0',
--   `realclick` mediumint(9) unsigned NOT NULL DEFAULT '0',
--   `clickcharge` mediumint(9) NOT NULL DEFAULT '0',
--   `totalview` mediumint(9) unsigned NOT NULL DEFAULT '0',
--   `viewcharge` mediumint(9) unsigned NOT NULL DEFAULT '0',
--   `dt` date NOT NULL DEFAULT '0000-00-00',
--   `partnerid` smallint(6) unsigned NOT NULL DEFAULT '0',
--   KEY `ix_zoneid` (`zoneid`,`dt`),
--   KEY `ix_dt` (`dt`),
--   KEY `ix_campaignid` (`bannerid`)
-- ) ENGINE=InnoDB DEFAULT CHARSET=latin1
-- /*!50100 PARTITION BY RANGE (TO_DAYS(dt))
-- (PARTITION p00 VALUES LESS THAN (0) ENGINE = InnoDB,
--  PARTITION p04 VALUES LESS THAN (734965) ENGINE = InnoDB,
--  PARTITION p05 VALUES LESS THAN (735025) ENGINE = InnoDB,
--  PARTITION MERGER_2012822 VALUES LESS THAN (735102) ENGINE = InnoDB,
--  PARTITION pcurrent_2012822 VALUES LESS THAN (735103) ENGINE = InnoDB,
--  PARTITION pcurrent_2012823 VALUES LESS THAN (735104) ENGINE = InnoDB) */;
-- /*!40101 SET character_set_client = @saved_cs_client */;

通常どおりインポートします。

1
quanta

パーティション構成でエラーを再現するために少し時間を費やしましたが、孤立したテーブルで正確なエラーを取得できません

120927 16:57:04 [エラー]テーブルの.frmファイルが存在するにもかかわらず、InnoDBの内部データディクショナリからテーブルreportingdb/v3_zone_date_cpm7k#P#pcurrent_2012926が見つからないか、開けません。

パーティションの.ibdファイルをデータディレクトリの外に移動すると(どういうわけか発生しているようです)、予期されるエラーが発生します。

[エラー] MySQLはテーブルハンドルを開こうとしていますが、テーブルfoo/v3_zone_date_cpm7k#P#pcurrent_2012822の.ibdファイルが存在しません。

チャットディスカッションから、古いバックアップファイルがあることがわかります。パーティション 'pcurrent_2012926'(一部のデータ損失)を実際に強制的に削除することができない場合、このバックアップを復元する手順は次のとおりです(残念ながら1か月分のデータ損失)。

  • メインサーバーのバックアップを取る(念のため!)
  • 別のサーバーにバックアップを復元する
  • テーブルのmysqldumpを取得します:_mysqldump -uuser -p reportingdb v3_zone_date_cpm7k > v3_zone_date_cpm7k.sql_
  • v3_zone_date_cpm7k.sqlをメインサーバーにコピーする
  • メインサーバーで、これを試みます:_DROP TABLE reportingdb.v3_zone_date_cpm7k_
  • それが機能する場合は、ダンプファイルをインポートします:_mysql -uuser -p reportingdb < v3_zone_date_cpm7k.sql_これにより、そのテーブルが復元されます(1か月前のテーブルを使用)
  • _DROP TABLE_が機能しない場合は、_v3_zone_date_cpm7k.frm_およびその他のファイルを別の場所に移動して、サーバーを再起動してください。次に、ダンプファイルをインポートします。

最後のステップは、孤立したテーブルがあることを通知するエラーメッセージに関するものです。

これは、InnoDB内に対応するテーブルがない孤立した.frmファイルがあることを意味します。孤立した.frmファイルは、手動で削除することで削除できます。 [src]

これが不要で、別の方法でパーティションを復元できることを願っています。これは最後の手段です。


ようやく初期エラーを再現しました。パーティションを復元することはほとんどありませんが、これが今後起こらないようにすることを理解しておくと役立ちます(バックアップ/復元プロセスの処理方法またはパーティションの作成方法の潜在的な問題)。

  • V3_zone_date_cpm7kを(バックアップとして)別の場所にコピーしました。
  • _DROP TABLE v3_zone_date_cpm7k_を発行する
  • v3_zone_date_cpm7kファイルをdatadirにコピーします。

    _desc v3_zone_date_cpm7k;_

    ERROR 1146 (42S02): Table 'v3_zone_date_cpm7k' doesn't exist

[エラー]テーブルの.frmファイルが存在するにもかかわらず、InnoDBの内部データディクショナリからテーブルv3_zone_date_cpm7k#P#p00が見つからないか、開けません。

3
Derek Downey

各InnoDBテーブルには、特別な番号が登録されています。これはテーブルスペースIDと呼ばれます。テーブルの作成時に割り当てられ、ibdata1内のデータディクショナリに登録される番号です。

この問題を回避する方法はありますが、これを達成するには多くのフープをジャンプする必要があります。 InnoDBテーブルを別のディスクにコピーし、任意の種類のDDLを実行し、テーブルデータをコピーしようとすると、テーブルスペースIDが一致しない可能性があることに注意してください。

この回復に関して私が今まで読んだ唯一の人は、あなたが参照したガイドである Chris Calender です。これについては以前に書いたことがあります。

あなたの問題はテーブルスペースID自体に関係している可能性があると思います。 9月28日の投稿で、私はこの同じ参照を見つけたDBホスティングクライアントを支援しました。彼の問題はこれでした:

このテーブルのtablespace_idは912でした。彼は.ibdファイルの古いコピーを復元しようとしました。それは912よりはるかに少ないtablespace_idを持っていました。これが私が彼がするのを助けたものです:

  • 別のMySQLインスタンスを作成
  • ストアドプロシージャを記述して、InnoDBテーブルを911回作成および削除します。
  • 作成されたInnoDBテーブル(現在、tablespace_idは912でした)
  • 破棄されたテーブルスペース
  • バックアップ.ibdファイルで切り替え
  • インポートされたテーブルスペース
  • MySQLDumpedテーブル
  • Mysqldumpを元のサーバーにインポートした

クライアントは彼がしなければならなかった30のテーブルを持っていました。私は彼のためにストアドプロシージャを書いただけです。私は悲惨な詳細にこだわりませんでした。それでも、クライアントはすべてのInnoDBテーブルを取り戻し、すべてのtablespace_idを正しく照合します。

あなたの場合、Chris Calenderの方法がパーティション分割されたテーブルで正しく機能するかどうかは正直わかりません。パーティション内のすべての.ibdファイルに同じtablespace_idsを持たせることを考えていると思います。

1
RolandoMySQLDBA