☰

mysql: no se puede eliminar la tabla, no existe, no se puede crear, la tabla existe

tag-icon • tag-icon mysql innodb
mysql: no se puede eliminar la tabla, no existe, no se puede crear, la tabla existe

Después de una caída del servidor, tenemos algunos problemas muy extraños con una referencia de tabla en particular.

Al optar por una restauración desde la copia de seguridad, la base de datos se eliminó y se cargó un volcado SQL de copia de seguridad, solo que esto falla en la creación de la tabla porque cache_contentaparece el error "la tabla ya existe".

mysql> create table cache_content( id int NOT NULL DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8; ERROR 1005 (HY000): Can't create table '****.cache_content' (errno: -1) mysql> drop table cache_content; ERROR 1051 (42S02): Unknown table 'cache_content'

Curiosamente, la tabla desplegable eliminó el archivo .frm pero no el .ibd (si existe), la tabla de creación creará el archivo .ibd pero no el archivo .frm.

Probé numerosos métodos de restauración, incluida la importación del volcado a una nueva base de datos (completado sin problemas), apagué mysql y copié los archivos .frm y .ibd relevantes, y luego uséidbconectarpara intentar adjuntar esta versión "buena conocida":

... Space id: 1952673645 (0x74636F6D) Next record at offset: 74 TABLE_ID of `****/`.`cache_content` can not be 0 ...

Al verificar las tablas relacionadas en information_schema, puedo ver que este es el caso y que TABLESPACE se ha asignado a 0

mysql> select * from INNODB_SYS_TABLES where `SCHEMA`="*****";
+----------+--------+--------------------------+------+--------+-------+
| TABLE_ID | SCHEMA | NAME                     | FLAG | N_COLS | SPACE |
+----------+--------+--------------------------+------+--------+-------+
...

|    19791 | *****  | cache_content            |    1 |      9 |     0 |
+----------+--------+--------------------------+------+--------+-------+
N rows in set (0.01 sec)

mysql> select * FROM INNODB_SYS_INDEXES where TABLE_ID=19791;
+----------+--------+----------+------+----------+---------+-------+
| INDEX_ID | NAME   | TABLE_ID | TYPE | N_FIELDS | PAGE_NO | SPACE |
+----------+--------+----------+------+----------+---------+-------+
|     7919 | expire |    19791 |    0 |        1 |  311158 |     0 |
+----------+--------+----------+------+----------+---------+-------+
1 row in set (0.00 sec)

Versión del servidor: Percona-Server-server-55-5.5.27-rel28.0.291.rhel6.x86_64

Ahora estoy bastante seguro, por la lectura que he hecho, de que eliminar ibdata1 ib_logfile* puede ser la única forma de limpiar esta referencia "fantasma".

Mi pregunta: ¿Hay alguna forma de limpiar estas referencias fantasma para permitir que la tabla se restaure desde la copia de seguridad?

Respuesta1

Al final opté por restaurar todas las bases de datos a partir de copias de seguridad,

  1. mysqldump --all-databases --triggers > /path/to/dumpfile.sql
  2. service mysql shutdown
  3. rm -rf /path/to/datadir && mkdir /path/to/datadir && chown mysql.mysql /path/to/datadir
  4. iptables -I INPUT -p tcp --dport 3306 -j REJECT && service mysql start
  5. mysql_install_db --datadir=/path/to/datadir
  6. mysql < /path/to/dumpfile.sql
  7. Elimine y restaure cualquier base de datos que no estuviera intacta durante 1. desde copias de seguridad individuales
  8. service mysql restart && service iptables restart

Dejo esta respuesta aquí y la pregunta no aceptada para la próxima semana; Estoy esperanzadoalguienpuede proporcionar una solución donde no es necesario reconstruir todo el ibdata.

información relacionada