Arquitetura InnoDB

ANÁLISE

• De alguma forma, você perdeu os arquivos my_user.frme . my_user.ibdO dicionário de dados ainda tem uma entrada para essa tabela.
• Você não pode executar DROP TABLE my_user;porque o mysqld procura pelo my_user.frmprimeiro. Como não é my_user.frm, a tabela não pode ser descartada.
• Embora my_user.frmnão exista, você não pode executar CREATE TABLE my_user ...porque o mysqld pensa que está OK para criar a tabela, mas então adia para o mecanismo de armazenamento. InnoDB diz "Já tenho o tablespace_id de my_user registrado".

Esta sequência de eventos pode ser comprovada se você criar a tabela usando MyISAM. mysqld irá permitir isso. Uma vez que você muda para o InnoDB, ele volta direto para o dicionário de dados, que está com defeito nessa entrada.

tenho duas sugestões

SUGESTÃO #1

Não crie mais a tabela com esse nome. Usar um nome de tabela diferente

CREATE TABLE my_usertable (id INT AUTO_INCREMENT NOT NULL, username VARCHAR(255), group_id VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

Isso resultará na alteração do nome da tabela no código do aplicativo

SUGESTÃO #2

• mysqldump todos os dados, gatilhos e procedimentos armazenados
• backup ibdata1
• excluir ibdata1
• recarregar o mysqldump
• Etapas detalhadas da minha postagem do StackOverflow

Eu lidei com esse problema antes no meu post InnoDB table SELECT retorna ERROR 2006 (HY000): O servidor MySQL foi embora (após queda de energia)

Apenas para adicionar minha solução, pois tive um problema semelhante.

TL;DR

• Recrie a tabela com a mesma especificação de chave estrangeira, mas com um nome diferente do anteriormente mantido pela tabela.
• Solte a tabela resultante (também descartará a chave estrangeira órfã original)
• Recriar tabela com chave original ou sem chave estrangeira

Detalhe

Eu me deparei com a situação desagradável em que uma instrução ALTER TABLE falhou devido a uma chave estrangeira não ter sido descartada anteriormente. Isso levou a algumas inconsistências no dicionário de dados do InnoDB (provavelmente devido a http://bugs.mysql.com/bug.php?id=58215 ).

Pergunta relacionada aqui: https://stackoverflow.com/questions/16857451/error-in-foreign-key-constraint-on-a-droped-table

mysql> ALTER TABLE `visits` CHANGE COLUMN `variation_visitor_id` `variation_visitor_id` INT(11) NOT NULL  ;

Erro ao renomear de './db/#sql-482c_8448f' para './db/visits' (errno: 150)

mysql> SHOW ENGINE INNODB STATUS;

Error in foreign key constraint of table db/visits:
 FOREIGN KEY (`variation_visitor_id`) REFERENCES `variations_visitors` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Cannot find an index in the referenced table where the
referenced columns appear as the first columns, or column types
in the table and the referenced table do not match for constraint.
Note that the internal storage type of ENUM and SET changed in
tables created with >= InnoDB-4.1.12, and such columns in old tables
cannot be referenced by such columns in new tables.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html 
for correct foreign key definitippon.

Como não consegui recuperar a tabela #sql-482c_8448f para visitas, decidi reimportá-la de um backup feito pouco antes da alteração. No entanto, isso falhou. Na investigação:

• A restrição foi removida de INFORMATION_SCHEMA.TABLE_CONSTRAINTS e INFORMATION_SCHEMA.STATISTICS
• Mas a restrição ainda estava visível em INFORMATION_SCHEMA.INNODB_SYS_FOREIGN;
• A tabela não existia, então não pude descartar a chave estrangeira
• não consegui criar a tabela sem erros

SQL/Erros

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN WHERE ID='db/fk_visits_variations_visitors1';

+-----------------------------------+-----------+------------------------+--------+------+
| ID                                | FOR_NAME  | REF_NAME               | N_COLS | TYPE |
+-----------------------------------+-----------+------------------------+--------+------+
| db/fk_visits_variations_visitors1 | db/visits | db/variations_visitors |      1 |   48 |
+-----------------------------------+-----------+------------------------+--------+------+

Tentar recriar a tabela sem a chave estrangeira causou um erro 150

mysql>

SET UNIQUE_CHECKS = 0;
SET FOREIGN_KEY_CHECKS = 0;

CREATE TABLE `visits` (
  `id` INT(11) NOT NULL AUTO_INCREMENT  ,
  `variation_visitor_id` INT(11) NOT NULL  ,
  PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SET FOREIGN_KEY_CHECKS = 1;
SET UNIQUE_CHECKS = 1;

ERROR 1005 (HY000) at line 26: Can't create table 'db.visits' (errno: 150)

mysql> SHOW ENGINE INNODB STATUS;

Error in foreign key constraint of table db/visits:
there is no index in the table which would contain
the columns as the first columns, or the data types in the
table do not match the ones in the referenced table
or one of the ON ... SET NULL columns is declared NOT NULL. Constraint:
,
  CONSTRAINT "fk_visits_variations_visitors1" FOREIGN KEY ("variation_visitor_id") REFERENCES "variations_visitors" ("id") ON DELETE NO ACTION ON UPDATE NO ACTION

Tentar criá-lo com causou um erro 121

mysql>

SET UNIQUE_CHECKS = 0;
SET FOREIGN_KEY_CHECKS = 0;

CREATE TABLE `visits` (
  `id` INT(11) NOT NULL AUTO_INCREMENT  ,
  `variation_visitor_id` INT(11) NOT NULL  ,
  PRIMARY KEY (`id`),
  KEY `fk_visits_variations_visitors1` (`variation_visitor_id`),
  CONSTRAINT `fk_visits_variations_visitors1` FOREIGN KEY (`variation_visitor_id`) REFERENCES `variations_visitors` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SET FOREIGN_KEY_CHECKS = 1;
SET UNIQUE_CHECKS = 1;

ERROR 1005 (HY000) at line 26: Can't create table 'db.visits' (errno: 121)

mysql> SHOW ENGINE INNODB STATUS;

Error in foreign key constraint creation for table `db`.`visits`.
A foreign key constraint of name `db`.`fk_visits_variations_visitors1`
already exists. (Note that internally InnoDB adds 'databasename'
in front of the user-defined constraint name.)
Note that InnoDB's FOREIGN KEY system tables store
constraint names as case-insensitive, with the
MySQL standard latin1_swedish_ci collation. If you
create tables or databases whose names differ only in
> the character case, then collisions in constraint
names can occur. Workaround: name your constraints
explicitly with unique names.

Eventualmente, usei um novo nome de chave estrangeira. Eu não esperava que isso funcionasse, mas permitiu que a tabela fosse criada.

mysql>

SET UNIQUE_CHECKS = 0;
SET FOREIGN_KEY_CHECKS = 0;

CREATE TABLE `visits` (
  `id` INT(11) NOT NULL AUTO_INCREMENT  ,
  `variation_visitor_id` INT(11) NOT NULL  ,
  PRIMARY KEY (`id`),
  KEY `fk_visits_variations_visitors2` (`variation_visitor_id`),
  CONSTRAINT `fk_visits_variations_visitors2` FOREIGN KEY (`variation_visitor_id`) REFERENCES `variations_visitors` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

SET FOREIGN_KEY_CHECKS = 1;
SET UNIQUE_CHECKS = 1;

Simplesmente descartar a tabela depois removeu o registro errante em INFORMATION_SCHEMA.INNODB_SYS_FOREIGN, permitindo uma importação com o nome da chave estrangeira original.

Existe uma maneira simples de contornar isso, embora seja certo que, em certas circunstâncias, você pode não querer fazer isso. Como esse problema decorre de uma referência interna do InnoDB, você pode simplesmente criar esta tabela com o mesmo nome, mesmas colunas, apenas usando um mecanismo de armazenamento diferente. Encontrei isso em um escravo do MySQL e, embora o mestre do qual eu estava replicando fosse o InnoDB, recriei essa tabela com o MyISAM e consegui voltar a funcionar. Eu escolhi especificamente o InnoDB para meu mecanismo de armazenamento no mestre e, em algumas tabelas, seria importante no escravo também, mas, neste caso, não teve impacto neste escravo para esta tabela, então foi uma maneira rápida para contornar esta questão. Descartar todo o banco de dados teria sido um projeto muito maior.

Você perdeu os dados da tabela, mas o registro sobre esta tabela ainda existe em "mysql/data/ibdata1". A solução mais fácil é criar esta tabela em algum outro banco de dados e depois copiar os arquivos:

mysql/data/**dummy_database**/my_user.frm

mysql/data/**dummy_database**/my_user.ibd

para o seu próprio:

mysql/data/**yours_database**/my_user.frm

mysql/data/**yours_database**/my_user.ibd

O que funcionou para mim foi:

• primeiro mova os arquivos .frm e .ibd para outro diretório, por exemplo /tmp/tablebackup *
• agora extraindo a estrutura da tabela do arquivo .frm usando do ** mysqlfrmdo Oracle mysql-utitilies(porque não tinha outra cópia/backup da estrutura) ex:/usr/bin/mysqlfrm --diagnostic /tmp/tablebackup/MyTable.frm
• crie uma nova tabela com a estrutura da tabela original, mas com um nome diferente (por exemplo, digamos que a tabela com o problema é MyTableentão criei uma tabela MyTableBcom a estrutura da tabela original)
• em seguida renomeie a tabela para o nome original de dentro do mysql, por exemplo: RENAME TABLE `MyTableB` TO `MyTable`;(observe que isso só funciona se você não tiver innodb_force_recoverydefinido em seu my.cnf)
• agora no mysql execute:ALTER TABLE `MyTable` DISCARD TABLESPACE;
• então copie o .ibdarquivo original (somente o arquivo .ibd, não o arquivo .frm) de volta para o diretório do banco de dados mysql de onde ele foi originalmente movido (não deve haver um arquivo .ibd existente neste momento porque ele é removido pelo DISCARD TABLESPACEcomando)
• e agora corraALTER TABLE `MyTable` IMPORT TABLESPACE;

* Reiniciei o mysql após esta etapa, mas não tenho certeza se isso é necessário

** mysql-utilities pode requerer instalação mysql-connector-pythonprimeiro