Помилка: Простір таблиць для таблиці xxx існує. Будь ласка, відкиньте простір таблиць перед ІМПОРТ

Я досить новачок у MySQL, і я отримую досить цікаву помилку, щодо якої я не можу знайти допомогу через google та пошук stackoverflow.

Я запускаю локальний сервер MySQL 5.6.10 на MacOS 10.8.3 і керую моєю базою даних через Navicat Основи для 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, або, можливо, права дозволу користувача можуть мати відношення до цього, але я тут просто гіпотезую.

Тут трохи пізно, але, як правило, я бачив, що ця проблема виникає, коли ви отримуєте помилку "повного простору таблиць" під час запуску в режимі "innodb_file_per_table". Не вдаючись до занадто багато деталей (детальніше тут ), простір таблиць сервера бази даних визначається параметром innodb_data_file_path і за замовчуванням є досить малим. Навіть зростаючий, "повний простір таблиць" все ще може виникати з більшими запитами, і такі (там зберігається багато "не" табличних "речей", скасовувати журнали, кеші тощо).

У будь-якому випадку я виявив, що якщо ви заглянете в каталог ОС, де зберігаються файли за столом, / var / lib / mysql за замовчуванням на OSX, / usr / local / var / mysql з ibrec homebrew, ви знайдете осиротілий файл 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/

Одне застереження, але переконайтеся, що що-небудь викликає проблему спочатку, наприклад, тривалий запит, заблокована таблиця тощо ... був очищений. Інакше ви просто вдруге опинитесь з іншим осиротілим.

Користувачі Xampp та Mamp

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

Для користувачів WAMP [Windows 7 Ultimate x64-bit]:

Я погоджуюся з тим, що сказав DangerDave, і тому я роблю відповідь доступною для користувачів WAMP .

Примітка. Перш за все, ви повинні перейти до своєї папки .. \ WAMP \ Bin \ MySQL \ MySQL [Ваша версія MySQL] \ Дані .

Тепер ви побачите папки всіх ваших баз даних

• Двічі клацніть папку бази даних, в якій є таблиця порушень, щоб її відкрити
• Файлу [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 для вихідної таблиці. Це має успішно скинути таблицю, і InnoDB повинен надрукувати попередження до журналу помилок про відсутність .ibd-файлу.

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

моя система XAMPP для Windows MariaDB v 10.1.8

У моєму випадку єдиним робочим рішенням було:

1. СТВОРИТИ СТІЛЬКИ bad_tableДВИГАТИ = MyISAM ...
2. rm bad_table.ibd
3. ДРОПІЛЬНИЙ СТОЛ 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...

з таблицею drop не працює так само, як і з таблицею alter ...

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 я видав успішну команду drop в обох таблицях

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)

EDIT: Я збирався додати в

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

Таким чином, збігається ідентифікатор простору таблиць у словнику даних та файл; таким чином імпорт простору таблиць вдався.

Це може дати вам більшу впевненість у роботі з деякими "gotcha" InnoDB під час процесу відновлення або навіть передачі файлів.

реф

Ось такі кроки рішення:

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

Мав це питання кілька разів. Якщо у вас є велика БД і ви хочете спробувати уникнути резервного копіювання / відновлення (із доданою відсутньою таблицею), спробуйте кілька разів вперед і назад:

КОРОТКА ТАБЛИКА my_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 selected to backup-> export (as .sql).

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

Ймовірно, у мене була резервна копія зіпсованого столу.

Ця помилка виникає, коли ви призупиняєте деякі функції. Як і виконання запиту нижче неправильним зовнішнім ключем.

set foreign_key_checks=0

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

Значення за замовчуванням для заварки для 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замовчуванням, яке мене покусало, було відсутність порту, тому мережа була за замовчуванням для 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 в таблицю.

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

Я видаляю лише стару БД, що знаходиться в моєму локальному хості, безпосередньо з wamp, Зупиняю всі сервіси, Перейдіть на wamp / bin / mysql / mysql [версія] / data, і я знайшов БД з проблемами, видаляю її і запускаю знову wamp усі служби створити знову свою базу даних, і це буде зроблено. Тепер ви можете імпортувати свої таблиці,

Те, як я виявив "вирішити" цю проблему, досить дратує, але є сценарій, який вирішує цю проблему.

По суті, вам потрібні файли 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 / yourdabase Folder, видаліть "yourdabase Folder"

2. Знову вам доведеться створити нову базу даних та імпортувати старий файл sql. Це буде робота

Дякую

Мені довелося знайти свій каталог даних MySQL:

ПОКАЗУЙТЕ ВАРІАБЛІЇ, де Variable_Name ПОДОБАЄТЬСЯ "% dir"

Потім примушуйте видалити цю базу даних:

sudo rm -rf

Ви можете запустити наступний запит як користувач root mysql

drop tablespace `tableName`

Ей, розробники не витрачають час. Просто видаліть базу даних, що містить таблиці, та знову імпортуйте цілі таблиці. Економте час = час - це гроші. Ура.