Ошибка: табличное пространство для таблицы xxx существует. Пожалуйста, УДАЛИТЕ табличное пространство перед ИМПОРТОМ

Я довольно новичок в MySQL, и я получаю довольно интересную ошибку, из-за которой я не могу найти никакой помощи через Google и поиск в stackoverflow.

Я использую локальный сервер MySQL 5.6.10 на MacOS 10.8.3 и управляю своей базой данных с помощью Navicat Essentials для MySQL.

Ошибка, которую я получаю, заключается в том, что после запуска и управления моей базой данных в течение нескольких дней / недель все в порядке (что выглядит не полностью) приводит к удалению некоторых таблиц, которые я создал с помощью запросов из 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, или, возможно, права доступа пользователя могут иметь отношение к нему, но я просто предполагаю здесь.

Немного поздно здесь, но обычно я видел, что эта проблема возникает, когда вы получаете ошибку 'tablespace full' при работе в режиме 'innodb_file_per_table'. Не вдаваясь в подробности (подробнее здесь ), табличное пространство сервера базы данных определяется параметром innodb_data_file_path и по умолчанию довольно мало. Даже увеличенный, «табличное пространство заполнено» может все еще встречаться с большими запросами и тому подобным (там хранится много «незаполненных» «вещей», отменяются журналы, кэши и т. Д.).

В любом случае, я обнаружил, что если вы посмотрите в каталог ОС, где хранятся файлы для каждой таблицы, / var / lib / mysql по умолчанию в OSX, / usr / local / var / mysql с homebrew iirc, вы найдете потерянный файл tablename.ibd без его обычного сопутствующего файла tablename.frm. Если вы переместите этот файл .ibd в безопасное временное место (просто для безопасности), это должно решить проблему.

$ ls /var/lib/mysql

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

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

Одно предостережение: убедитесь, что все, что изначально вызывало проблему, например, длительный запрос, заблокированная таблица и т. Д., Было очищено. В противном случае вы просто получите другой потерянный файл .ibd при повторной попытке.

Пользователи Xampp и Mamp

Произошла та же ошибка при импорте базы данных (после ее очистки) через MySQL. Я обнаружил, что у меня остался tablename.ibdфайл, а все остальные были удалены. Я удалил его вручную из, mysql/data/database_nameи ошибка исчезла.

Для пользователей WAMP [Windows 7 Ultimate x64-bit]:

Я согласен с тем, что сказал DangerDave, и поэтому я делаю ответ доступным для пользователей WAMP .

Примечание. Прежде всего, вам нужно перейти в папку .. \ WAMP \ Bin \ MySQL \ MySQL [Ваша версия MySQL] \ Data .

Теперь вы увидите папки всех ваших баз данных

• Дважды щелкните папку базы данных, в которой находится таблица с ошибками, чтобы открыть ее
• Там не должно быть файла [Your offending MySQL table name].frm, вместо этого должен быть файл[Your offending MySQL table name].ibd
• Удалить [Your offending MySQL table name].ibd
• Затем удалите его из корзины тоже
• Затем запустите ваш запрос MySQL к базе данных, и все готово

Если .idbпосле удаления вы снова создадите заново, прочитайте этот ответ.

Вот как это работает со мной. У меня был .idbфайл без его соответствия, .frmи всякий раз, когда я удаляю .idbфайл, база данных создает его заново. и я нашел решение в одной строке в документации MySQL (часть табличного пространства не существует )

1- Создайте соответствующий файл .frm в каком-либо другом каталоге базы данных и скопируйте его в каталог базы данных, где находится бесхозная таблица.

2- Выпустите DROP TABLE для оригинальной таблицы. Это должно успешно удалить таблицу, и InnoDB должен напечатать предупреждение в журнал ошибок об отсутствии файла .ibd.

Я скопировал другой .frmфайл таблицы и назвал его как мою отсутствующую таблицу, затем сделал обычный запрос удаления таблицы и вуаля, он работал, и таблица удалялась нормально!

моя система XAMPP на окнах MariaDB v 10.1.8

В моем случае единственным рабочим решением было:

1. CREATE TABLE bad_tableENGINE = MyISAM ...
2. rm bad_table.ibd
3. DROP TABLE bad_table

Это именно то, что я сделал в mariadb 10.2.16 на fedora, когда у меня была таблица, которая показывала точно такие же ошибки в файле журнала, я полагаю ...

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

создать таблицу также не удается так:

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)

и теперь все квадраты, и я могу воссоздать единый стол ...

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 к двум 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

Я заменил приведенный выше более длинный список команд для более короткого списка, который можно сократить еще с помощью *

В моем случае:

Сначала удалите tableName.ibdв своей базе данных директорию из Mysql, а затем снова запустите:

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;

Я получил ту же ошибку при запуске его на Wampserver при попытке создать таблицу пользователей. Я нашел файл users.ibd и после удаления этого файла снова запустил команду migrate, и она заработала. Файл на моей машине с Windows находился в папке wamp / bin / mysql / mysql5.6.12 / data / myproject.

Решение

Однако более простой вариант заключается в следующем: перезапустите MySQL, затем выполните те же четыре шага, как указано ниже:

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

Таким образом, идентификатор табличного пространства в словаре данных и файл совпадают; таким образом, импорт табличного пространства завершился успешно.

Это может дать вам большую уверенность в работе с некоторыми "хитами" InnoDB во время процесса восстановления или даже передачи файлов.

ссылка

Вот шаги решения:

1. сделайте резервную копию вашей базы данных (структура с опцией удаления и данными)
2. остановить службу двигателя MySQL
3. удалить каталог базы данных вручную из mysql / data
4. запустить двигатель MySQL
5. создать новую базу данных с любым именем, отличным от вашей поврежденной базы данных
6. создать единую таблицу с именем поврежденной таблицы внутри новой базы данных (это секрет). и лучше создать таблицу с точно такой же структурой.
7. переименовать базу данных в старую поврежденную базу данных
8. восстановите свою резервную копию, и ваша таблица будет работать нормально.

Имел эту проблему несколько раз. Если у вас большая БД и вы хотите избежать резервного копирования / восстановления (с добавленной отсутствующей таблицей), попробуйте несколько раз назад и вперед:

DROP TABLE my_table;

ALTER TABLE my_table DISCARD TABLESPACE;

-и-

rm my_table.ibd (сирота без соответствующего my_table.frm) находится в каталоге / var / lib / mysql / my_db /

-а потом-

СОЗДАЙТЕ ТАБЛИЦУ, ЕСЛИ НЕ СУЩЕСТВУЕТ my_table(...)

Удаление / перемещение tablename.ibd точно не работает для меня.

Как я это решил

Так как я собирался удалить поврежденную и несуществующую таблицу, я сделал резервную копию других таблиц, перейдя в phpmyadmin-> database-> export-> selected table в backup-> export (as .sql).

После этого я выбрал значок базы данных рядом с именем базы данных, а затем отбросил его. Создана новая база данных. Выберите вашу новую базу данных-> импорт-> выберите файл, который вы скачали ранее-> нажмите импорт. Теперь у меня есть старые рабочие таблицы и удаленная поврежденная таблица. Теперь я просто создаю таблицу, которая выдает ошибку.

Вероятно, у меня была более ранняя резервная копия поврежденной таблицы.

Эта ошибка возникает при приостановке некоторых функций. Как и при выполнении запроса ниже с неправильным внешним ключом.

set foreign_key_checks=0

Была точно такая же проблема; Я бы добавил варево mysql@5.6(после ранее 5,5).

Значения по умолчанию для brew - 5.6, innodb_file_per_table=1а для 5.5 - innodb_file_per_table=0.

Ваш существующий ibdata1файл (объединенные данные innodb) по-прежнему будет содержать ссылки на таблицы, которые вы пытаетесь создать / удалить. Либо измените innodb_file_per_tableобратно на 0, либо удалите файл данных ibdata1 ( это приведет к потере всех ваших данных, поэтому сначала убедитесь, что вы mysqldump, или у вас уже есть дамп .sql ).

Вторым по mysql@5.6умолчанию brew, который меня поразил , было отсутствие порта, поэтому по умолчанию в сети использовались сокеты unix, и клиент mysql продолжал сообщать:

ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32

Я добавил <string>--port=3306</string>в .plistмассив, но вы также можете указать port=3306в своемmy.cnf

Запустите brew services stop mysql@5.6внесите измененияbrew services start mysql@5.6

Попытка отбросить табличное пространство может привести к другим ошибкам. Для меня я получил следующую ошибку:

DROP TABLESPACE `tablename`

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

Моим решением было сбросить базу данных. Это удалит все связанные с ним табличные пространства и позволит вам снова создавать таблицы.

Если у вас есть другой сервер с хорошей версией той же таблицы, вы можете сделать копию (table_copy), перенести table_copy на проблемный сервер. Затем удалите проблемную таблицу и переименуйте table_copy в table.

Для меня это помогло просто перейти в каталог MYSQL DATA в / var / lib / mysql / {db_name} (linux) и удалить файл {table_name} .ibd, который совпадает с именем папки.

Я только удаляю свою старую БД, расположенную на моем локальном хосте, прямо из wamp, Остановка всех сервисов, Зайдите в wamp / bin / mysql / mysql [версия] / data, и я нашел БД с проблемами, я удаляю ее и снова запускаю wamp all services, создайте заново свою базу данных, и все готово, теперь вы можете импортировать ваши таблицы,

Способ, который я нашел, чтобы «решить» эту проблему, довольно раздражает, но есть сценарий, который ее обрабатывает.

По сути, вам нужно ibdata1и ib_logfile*файлы , чтобы уйти (они содержат отображения внешних ключей, между прочим). Единственный безопасный способ сделать это - экспортировать все ваши базы данных, остановить mysql, удалить файлы, запустить mysql, а затем импортировать файлы.

Сценарий, который помогает решить эту проблему, - https://github.com/uberhacker/shrink-ibdata1 , хотя заявленное назначение этого сценария иное, оно действительно решает проблему.

Единственный способ, которым это работало для меня, было:

1. Создать похожую таблицу
2. Скопируйте файлы .frm и .idb новой аналогичной таблицы в имя поврежденной таблицы.
3. Исправить разрешения
4. Перезапустите MariaDB
5. Бросьте испорченный стол

Если у вас возникла эта проблема, и у вас нет другого варианта, поменяйте движок на любой другой движок, например «myisam», затем попытайтесь создать таблицу.

Отказ от ответственности: это неверный ответ, так как у вас могут быть ограничения внешнего ключа, которые не будут поддерживаться другим механизмом хранения. У каждого механизма хранения есть своя специализация для хранения и доступа к данным, эти моменты также должны быть приняты во внимание.

Пожалуйста, УДАЛИТЕ табличное пространство перед ИМПОРТОМ

Я получил то же самое решение проблемы ниже

1. Сначала вы должны удалить имя вашей базы данных. если ваша база данных не удаляется, вы отправляете меня. Для системы Windows ваш каталог будет C: / xampp / mysql / data / yourdabasefolder удалить "yourdabasefolder"

2. Снова вы должны создать новую базу данных и импортировать старый файл sql. Это будет работа

Спасибо

Я должен был найти мой каталог данных MySQL:

ПОКАЗАТЬ ПЕРЕМЕННЫЕ ГДЕ Variable_Name LIKE "% dir"

Затем принудительно удалите эту базу данных:

sudo rm -rf

Вы можете запустить следующий запрос от имени пользователя root.

drop tablespace `tableName`

Эй, разработчики не тратьте свое время. Просто удалите базу данных, содержащую таблицы, и снова импортируйте целые таблицы. Экономьте время = время это деньги. Приветствия.