Błąd: istnieje przestrzeń tabel dla tabeli xxx. Proszę ODRZUCIĆ przestrzeń tabel przed IMPORTEM

Jestem całkiem nowy w MySQL i otrzymuję całkiem interesujący błąd, w którym nie mogę znaleźć żadnej pomocy za pośrednictwem google i wyszukiwania stackoverflow.

Używam lokalnego serwera MySQL 5.6.10 na MacOS 10.8.3 i zarządzam moją bazą danych przez Navicat essentials for MySQL.

Pojawia się błąd, który polega na tym, że po uruchomieniu i zarządzaniu moją bazą danych przez kilka dni / tygodni coś powoduje (wydaje się niecałkowicie) usunąć niektóre tabele, które utworzyłem za pomocą zapytań z Navicat.

Kiedy próbuję uruchomić zapytania przy użyciu tych tabel, Navicat ostrzega mnie, że dana tabela nie istnieje. Jak dotąd dobrze - oto dobra część:

Kiedy próbuję TWORZYĆ tabelę, np. O nazwie „temp”, która tam była wcześniej, pojawia się następujący komunikat o błędzie:

Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.

Jeśli jednak spróbuję usunąć tabelę lub odrzucić obszar tabel dla tej tabeli, użyj

DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;

Otrzymuję następujące komunikaty o błędach:

Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist

Oznacza to, że radzę wyrzucić obszar tabel, ale kiedy próbuję to zrobić, tabela nie istnieje. Czy jest możliwe, że jakaś pozostałość tej tabeli znajduje się w innym miejscu, w którym zapytanie DISCARD nie sprawdza? I czy ktoś ma pomysł, co może to wszystko wywołać - zupełnie przypadkowo, jak się wydaje?

Jak powiedziałem, jestem nowy w tym temacie i prawie nie mam pojęcia. Podejrzewam, że ponowne uruchomienie laptopa, tj. Zresetowanie mojego lokalnego serwera MySQL, lub może mieć z tym związek uprawnienia użytkownika, ale stawiam tu tylko hipotezę.

Trochę późno tutaj, ale ogólnie widziałem ten problem, gdy pojawia się błąd „pełna przestrzeń tabel” podczas pracy w trybie „innodb_file_per_table”. Bez wchodzenia w zbyt wiele szczegółów (więcej tutaj ), obszar tabel serwera bazy danych jest zdefiniowany przez ustawienie innodb_data_file_path i domyślnie jest raczej mały. Nawet powiększony, „pełny obszar tabel” może nadal występować przy większych zapytaniach i tym podobnych (przechowywanych jest tam wiele „rzeczy” niebędących tabelami, cofanie dzienników, pamięci podręcznych itp.).

W każdym razie stwierdziłem, że jeśli zajrzysz do katalogu systemu operacyjnego, w którym przechowywane są pliki na tabelę, / var / lib / mysql domyślnie w systemie OSX, / usr / local / var / mysql z homebrew iirc, znajdziesz osierocony plik tablename.ibd bez jego normalnego towarzyszącego pliku tablename.frm. Przeniesienie tego pliku .ibd do bezpiecznej lokalizacji tymczasowej (na wszelki wypadek) powinno rozwiązać problem.

$ 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/

Jedno zastrzeżenie, upewnij się, że wszystko, co pierwotnie powoduje problem, np. Długo działające zapytanie, zablokowana tabela itp., Zostało usunięte. W przeciwnym razie po drugiej próbie otrzymasz kolejny osierocony plik .ibd.

Użytkownicy Xampp i Mamp

Wystąpił ten sam błąd podczas importowania bazy danych (po jej opróżnieniu) przez MySQL. Okazało się, że został mi tablename.ibdplik, podczas gdy wszystkie inne zostały usunięte. Usunąłem go ręcznie z mysql/data/database_namei błąd zniknął.

Użytkownicy WAMP [Windows 7 Ultimate x64-bit]:

Zgadzam się z tym, co powiedział DangerDave, dlatego udostępniam odpowiedź użytkownikom WAMP .

Uwaga: Przede wszystkim musisz przejść do folderu .. \ WAMP \ Bin \ MySQL \ MySQL [Twoja wersja MySQL] \ Data .

Teraz zobaczysz foldery wszystkich swoich baz danych

• Kliknij dwukrotnie folder bazy danych, która zawiera nieprawidłową tabelę, aby ją otworzyć
• Nie powinno być pliku [Your offending MySQL table name].frm , zamiast tego powinien być plik[Your offending MySQL table name].ibd
• Usuń plik [Your offending MySQL table name].ibd
• Następnie usuń go również z Kosza
• Następnie uruchom zapytanie MySQL w bazie danych i gotowe

Jeśli .idbpo usunięciu ponownie odtworzysz plik, przeczytaj tę odpowiedź.

Tak to działało ze mną. Miałem .idbplik bez odpowiadającego mu pliku .frmi za każdym razem, gdy usuwam .idbplik, baza danych ponownie go tworzy. i znalazłem rozwiązanie w jednej linii w dokumentacji MySQL (część Tablespace nie istnieje )

1- Utwórz zgodny plik .frm w innym katalogu bazy danych i skopiuj go do katalogu bazy danych, w którym znajduje się tabela osierocona.

2- Wydanie DROP TABLE dla oryginalnej tabeli. Powinno to pomyślnie usunąć tabelę, a InnoDB powinien wydrukować ostrzeżenie w dzienniku błędów, że brakuje pliku .ibd.

Skopiowałem inny .frmplik tabeli i nadałem mu nazwę, jak moja brakująca tabela, a następnie wykonałem normalne zapytanie o tabelę upuszczania i voila, zadziałało, a tabela została normalnie usunięta!

mój system to XAMPP w systemie Windows MariaDB v 10.1.8

W moim przypadku jedynym rozwiązaniem pracy było:

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

Dokładnie to zrobiłem w mariadbie 10.2.16 na Fedorze, gdy miałem tabelę, która pokazywała dokładnie te same błędy w pliku dziennika, jak przypuszczam ...

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

Twój przebieg i błędy mogą się różnić, ale głównym, który zakładam, jest

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

z opuszczanym stołem nie działa tak dobrze, jak stół 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

tworzenie tabeli również kończy się niepowodzeniem:

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

Aby to naprawić, najpierw zrobiłem

create table  innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)

następnie w katalogu / var / lib / mysql / nazwa_bazy_danych wykonałem następujące czynności jako root potwierdzając nadpisanie innodb_table.ibd powodujące problemy

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

potem w konsoli mysql wydałem pomyślne polecenie drop na obu tabelach

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)

i wszystko jest teraz kwadratowe i mogę odtworzyć jeden pojedynczy stół ...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

EDYCJA: zamierzałem dodać plik

restorecon -Rv /var/lib/mysql/database_name 

polecenie po skopiowaniu bazy danych, aby uzyskać wszystkie konteksty selinux tak, jak powinny, nawet jeśli usuwamy je z bazy danych prawie natychmiast, ale alternatywnie możesz po prostu dodać opcję --archive lub -a do dwóch cp poleceń, więc tak, faktycznie opcja archiwum skraca to:

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

tylko po to, co uważam za lepsze i zachowuje kontekst selinux ustawiony dla już utworzonej tabeli.

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

Zastąpiłem powyższą dłuższą listę poleceń na krótszą listę, którą można jeszcze skrócić, na *

W moim przypadku:

Najpierw usuń tableName.ibdw katalogu bazy danych z MySQL, a następnie uruchom:

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;

Wystąpił ten sam błąd podczas uruchamiania go na wampserver podczas próby utworzenia tabeli użytkowników. Znalazłem plik users.ibd i po usunięciu tego pliku ponownie uruchomiłem polecenie migracji i zadziałało. Plik na moim komputerze z systemem Windows znajdował się w wamp / bin / mysql / mysql5.6.12 / data / myproject.

Rozwiązanie

Jednak łatwiejszą opcją jest: zrestartuj MySQL, a następnie wykonaj te same cztery kroki w następujący sposób:

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

W ten sposób zostanie dopasowany identyfikator obszaru tabel w słowniku danych i plik; w ten sposób import obszaru tabel powiódł się.

Może to dać ci większą pewność w radzeniu sobie z niektórymi problemami z InnoDB podczas procesu odzyskiwania, a nawet przesyłania plików.

ref

Oto kroki rozwiązania:

1. wykonaj kopię zapasową bazy danych (struktura z opcją upuszczania i danymi)
2. zatrzymaj serwis silnika mysql
3. usuń katalog bazy danych ręcznie z wnętrza mysql / data
4. uruchom silnik mysql
5. utwórz nową bazę danych o dowolnej nazwie innej niż Twoja uszkodzona baza danych
6. utwórz pojedynczą tabelę z nazwą uszkodzonej tabeli w nowej bazie danych (to jest sekret). i lepiej jest utworzyć tabelę o dokładnie takiej samej strukturze.
7. zmień nazwę bazy danych na starą uszkodzoną bazę danych
8. przywróć kopię zapasową, a tabela będzie działać poprawnie.

Miałem ten problem kilka razy. Jeśli masz dużą bazę danych i chcesz uniknąć tworzenia kopii zapasowych / przywracania (z dodaną brakującą tabelą), spróbuj kilka razy w tę iz powrotem:

DROP TABLE my_table;

ALTER TABLE my_table DISCARD TABLESPACE;

-i-

rm my_table.ibd (osierocony bez odpowiadającego my_table.frm) znajdujący się w katalogu / var / lib / mysql / my_db /

-i wtedy-

UTWÓRZ TABELĘ, JEŚLI NIE ISTNIEJE my_table(...)

Usunięcie / przeniesienie nazwy tabeli.ibd z pewnością nie zadziałało.

Jak to rozwiązałem

Ponieważ zamierzałem usunąć uszkodzoną i nieistniejącą tabelę, wykonałem kopię zapasową innych tabel, przechodząc do phpmyadmin-> database-> export-> wybrane tabele do kopii zapasowej-> eksportu (jako .sql).

Następnie wybrałem ikonę bazy danych obok nazwy bazy danych, a następnie ją upuściłem. Utworzono nową bazę danych. Wybierz swoją nową bazę danych -> importuj -> wybierz wcześniej pobrany plik -> kliknij import. Teraz mam moje stare tabele robocze i mam usuniętą uszkodzoną tabelę. Teraz po prostu tworzę tabelę, która generowała błąd.

Prawdopodobnie miałem wcześniejszą kopię zapasową uszkodzonej tabeli.

Ten błąd występuje podczas wstrzymania niektórych funkcji. Podobnie jak uruchomienie poniższego zapytania z nieprawidłowym kluczem obcym.

set foreign_key_checks=0

Miał dokładnie ten sam problem; Dodałem napar [email protected](po uprzednim napięciu 5,5).

Wartości domyślne naparu dla 5,6 to, innodb_file_per_table=1podczas gdy w 5,5 sąinnodb_file_per_table=0 .

Twój istniejący ibdata1plik (połączone dane innodb) nadal będzie zawierał odniesienia do tabel, które próbujesz utworzyć / upuścić. Zmień z innodb_file_per_tablepowrotem na 0 lub usuń plik danych ibdata1 ( spowoduje to utratę wszystkich danych, więc upewnij się, że najpierw mysqldump go lub masz już zrzut .sql ).

Inną [email protected]domyślną wartością, która mnie ugryzła, był brak portu, więc sieć była domyślnie oparta na gniazdach unix, a klient mysql wciąż raportował:

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

Dodałem <string>--port=3306</string>do .plisttablicy, ale możesz również określić port=3306w swoimmy.cnf

brew services stop [email protected]Następnie uruchom, wprowadź zmianybrew services start [email protected]

Próba usunięcia obszaru tabel może spowodować inne błędy. U mnie pojawił się następujący błąd:

DROP TABLESPACE `tablename`

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

Moim rozwiązaniem było porzucenie bazy danych. Spowoduje to usunięcie wszystkich powiązanych obszarów tabel i umożliwi ponowne utworzenie tabel.

Jeśli masz inny serwer z dobrą wersją tej samej tabeli, możesz wykonać kopię (table_copy), przenieść table_copy na serwer powodujący problem. Następnie usuń tabelę problemów i zmień nazwę table_copy na table.

Pomogło mi to po prostu przejść do katalogu MYSQL DATA w / var / lib / mysql / {nazwa_db} (linux) i upuścić plik {nazwa_tabeli} .ibd , który był taki sam jak nazwa folderu.

Usuwam tylko moją starą bazę danych znajdującą się na moim lokalnym hoście bezpośrednio z wampa, zatrzymuję wszystkie usługi, przechodzę do wamp / bin / mysql / mysql [wersja] / data i znalazłem bazę danych z problemami, usuwam ją i uruchamiam ponownie wamp wszystkich usług, utwórz ponownie swoją bazę danych i gotowe, teraz możesz zaimportować swoje tabele,

Sposób, w jaki znalazłem rozwiązanie tego problemu, jest dość denerwujący, ale istnieje skrypt, który go rozwiązuje.

Zasadniczo musisz usunąć pliki ibdata1i ib_logfile*(zawierają one między innymi mapowania kluczy obcych). Jedyny bezpieczny sposobem na to jest wyeksportowanie wszystkich baz danych, zatrzymanie mysql, usunięcie plików, uruchomienie mysql, a następnie zaimportowanie plików.

Skrypt, który pomaga rozwiązać ten problem jest https://github.com/uberhacker/shrink-ibdata1 , choć podanymi Celem tego skryptu jest inny, to nie rozwiąże problemu.

Jedyny sposób, w jaki to zadziałało, to:

1. Utwórz podobną tabelę
2. Skopiuj pliki .frm i .idb nowej podobnej tabeli do nazwy uszkodzonej tabeli.
3. Napraw uprawnienia
4. Uruchom ponownie MariaDB
5. Usuń uszkodzoną tabelę

jeśli masz ten problem i nie masz innej opcji, zmień silnik na inny, np. 'myisam', a następnie spróbuj utworzyć tabelę.

zastrzeżenie: to nie jest poprawna odpowiedź, ponieważ możesz mieć ograniczenia klucza obcego, które nie będą obsługiwane przez inny silnik pamięci masowej. Każdy silnik pamięci masowej ma swoją własną specjalizację w zakresie przechowywania i uzyskiwania dostępu do danych, należy też wziąć pod uwagę te punkty.

Proszę ODRZUCIĆ przestrzeń tabel przed IMPORTEM

Mam to samo rozwiązanie problemu znajduje się poniżej

1. Najpierw musisz usunąć nazwę bazy danych. jeśli twoja baza danych się nie usuwa, masz flow me. W systemie Windows twój katalog będzie C: / xampp / mysql / data / yourdabasefolder remove "yourdabasefolder"

2. Ponownie musisz utworzyć nową bazę danych i zaimportować stary plik sql. To będzie praca

Dzięki

Musiałem zlokalizować mój katalog danych MySQL:

POKAŻ ZMIENNE GDZIE Variable_Name LIKE "% dir"

Następnie wymuś usunięcie tej bazy danych:

sudo rm -rf

Możesz uruchomić następujące zapytanie jako użytkownik root mysql

drop tablespace `tableName`

Hej, programiści nie marnują czasu. Po prostu usuń bazę danych zawierającą tabele i ponownie zaimportuj całe tabele. Oszczędzaj czas = czas to pieniądz. Twoje zdrowie.