Após uma falha no servidor, estamos tendo alguns problemas muito estranhos com uma referência de tabela específica.
Optando por uma restauração do backup o banco de dados foi descartado e um dump SQL de backup foi carregado, só que isso falha na criação da tabela cache_content
com o erro "tabela já 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'
Estranhamente, a tabela suspensa removeu o arquivo .frm, mas não o arquivo .ibd (se existir), a tabela de criação criará o arquivo .ibd, mas não o arquivo .frm.
Eu tentei vários métodos de restauração, incluindo importar o dump para um novo banco de dados (concluído sem problemas), desligar o mysql e copiar os arquivos .frm e .ibd relevantes e, em seguida, usaridbconectarpara tentar anexar esta versão "boa":
... Space id: 1952673645 (0x74636F6D) Next record at offset: 74 TABLE_ID of `****/`.`cache_content` can not be 0 ...
Verificando as tabelas relacionadas em information_schema, posso ver que este é o caso e o TABLESPACE foi atribuído 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)
Versão do servidor: Percona-Server-server-55-5.5.27-rel28.0.291.rhel6.x86_64
Agora tenho quase certeza, pela leitura que fiz, de que remover ibdata1 ib_logfile* pode ser a única maneira de limpar essa referência "fantasma".
Minha pergunta: Existe alguma maneira de limpar essas referências fantasmas para permitir que a tabela seja restaurada do backup?
Responder1
No final optei por restaurar todos os bancos de dados a partir de backups,
mysqldump --all-databases --triggers > /path/to/dumpfile.sql
service mysql shutdown
rm -rf /path/to/datadir && mkdir /path/to/datadir && chown mysql.mysql /path/to/datadir
iptables -I INPUT -p tcp --dport 3306 -j REJECT && service mysql start
mysql_install_db --datadir=/path/to/datadir
mysql < /path/to/dumpfile.sql
- Elimine e restaure quaisquer bancos de dados que não estavam intactos durante 1. backups individuais
service mysql restart && service iptables restart
Estou deixando esta resposta aqui e a pergunta inaceitável para a próxima semana; eu estou esperandoalguémpode fornecer uma solução onde todo o ibdata não precisa ser reconstruído.