Ik ben vrij nieuw in MySQL en ik krijg een behoorlijk interessante foutmelding waarbij ik geen hulp kan vinden via Google en de stackoverflow-zoekopdracht.
Ik gebruik een lokale server van MySQL 5.6.10 op MacOS 10.8.3 en beheer mijn database via Navicat essentials for MySQL.
De fout die ik krijg is dat nadat ik mijn database een paar dagen/weken prima heb uitgevoerd en beheerd, iets triggert om (het lijkt onvolledig) enkele van de tabellen te verwijderen die ik heb gemaakt met behulp van query’s vanuit Navicat.
Als ik query’s probeer uit te voeren met behulp van deze tabellen, waarschuwt Navicat me dat de betreffende tabel niet bestaat. Tot nu toe zo goed – hier komt het goede deel:
Als ik de tabel probeer te CREREN, b.v. met de naam “temp”, die er eerder was, krijg ik de volgende foutmelding:
Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.
Als ik echter probeer de tafel te laten vallen, of de tablespace voor deze tafel probeer weg te gooien, gebruik dan
DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;
Ik krijg de volgende foutmeldingen:
Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist
Dus dat betekent dat ik het advies krijg om de tabelruimte weg te gooien, maar als ik dat probeer, bestaat de tabel niet. Is het mogelijk dat er een soort overblijfsel van deze tabel is op een andere plaats waar de DISCARD-query niet wordt gecontroleerd? En heeft iemand een idee wat dat allemaal zou kunnen veroorzaken – volledig willekeurig zoals het lijkt?
Zoals ik al zei, ik ben nieuw in het onderwerp en heb vrijwel geen idee. Ik vermoed dat het opnieuw opstarten van mijn laptop, d.w.z. het resetten van mijn lokale MySQL-server, of misschien gebruikersrechten er mee te maken kunnen hebben, maar ik veronderstel hier slechts een hypothese.
Antwoord 1, autoriteit 100%
Een beetje laat hier, maar over het algemeen heb ik dit probleem zien optreden wanneer je een ‘tablespace full’-fout krijgt bij het uitvoeren in een ‘innodb_file_per_table’-modus. Zonder al te veel in detail te treden (meer hier), wordt de tabelruimte van de databaseserver gedefinieerd door de instelling innodb_data_file_path en is standaard vrij klein. Zelfs groter gemaakt, kan de ‘tablespace full’ nog steeds voorkomen bij grotere queries en dergelijke (veel niet-table ‘dingen’ worden daarin opgeslagen, ongedaan maken van logs, caches, enz…).
Hoe dan ook, ik ontdekte dat als je in de OS-directory kijkt waar de bestanden-per-tabel zijn opgeslagen, /var/lib/mysql standaard op OSX, /usr/local/var/mysql met homebrew iirc, je’ Ik zal een verweesd tablename.ibd-bestand vinden zonder zijn normale begeleidende tablename.frm-bestand. Als u dat .ibd-bestand naar een veilige tijdelijke locatie verplaatst (voor de zekerheid), zou dat het probleem moeten oplossen.
$ ls /var/lib/mysql
table1.frm
table1.idb
table2.frm
table2.idb
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb
$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/
Eén waarschuwing echter: zorg ervoor dat wat het probleem oorspronkelijk veroorzaakt, b.v. langlopende query, vergrendelde tabel, enz… is gewist. Anders krijg je gewoon een ander verweesd .ibd-bestand als je het een tweede keer probeert.
Antwoord 2, autoriteit 59%
Xampp- en Mamp-gebruikers
Dezelfde fout gehad tijdens het importeren van een database (na het legen ervan) via MySQL. Ik ontdekte dat ik een tablename.ibd-bestand over had terwijl alle andere waren verwijderd.
Ik heb het handmatig verwijderd uit mysql/data/database_nameen de fout was verdwenen.
Antwoord 3, autoriteit 21%
Als de .idbopnieuw wordt gemaakt nadat je deze hebt verwijderd, lees dan dit antwoord.
Dit hoe het met mij werkte. Ik had de .idb-bestand zonder dat het corresponderend is .frmen telkens wanneer ik de .idb-bestand verwijder, maakt de database het opnieuw aan. En ik vond de oplossing in één regel in MySQL Documentatie (tablespace bestaat niet deel)
1 1 1 1 Maak een bijpassend .frm-bestand in een andere databasedirectory en kopieer deze naar de databasedirectory waar de weesafel zich bevindt.
2- Probleem druppeltabel voor de originele tabel. Dat zou de tabel met succes moeten laten vallen en Innodb moet een waarschuwing afdrukken naar het foutlogboek dat het. BIBD-bestand ontbrak.
Ik heb een andere tabel gekopieerd .frm-bestand en noem het als mijn ontbrekende tabel, en maak vervolgens een normale droptafelquery en voila, het werkte en de tafel wordt normaal gesproken gedaald!
Mijn systeem is XAMPP op Windows MariaDB V 10.1.8
4, Autoriteit 6%
In mijn geval:
Verwijder eerst tableName.ibdin uw databasedirectory van MySQL en tweede run:
ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;
5, Autoriteit 6%
In mijn geval was de enige werkoplossing:
- Tabel maken <
bad_tablemotor = myisam … - rm bad_table.ibd
- Drop Table
bad_table
6, Autoriteit 6%
Dit is precies wat ik deed in MariaDB 10.2.16 op Fedora toen ik een tabel had die precies dezelfde fouten in het logbestand liet zien, veronderstel ik …
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
Uw kilometers en fouten kunnen variëren, maar de belangrijkste die ik aanneem, is
...already exists though the corresponding table did not exist in the InnoDB data dictionary...
Met drop-tabel werkt niet, evenals altertabel …
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
Create tabel mislukt ook zoals SO:
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
Om dit te verhelpen, was wat ik deed als eerste
create table innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)
vervolgens deed ik in de directory /var/lib/mysql/database_name het volgende als root en bevestigde dat het overschrijven van innodb_table.ibd problemen veroorzaakte
cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb
toen terug in de mysql-console gaf ik een succesvol drop-commando op beide tabellen
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)
en alles is nu helemaal vierkant en ik kan die ene tafel opnieuw maken…
MariaDB [database_name]> create table innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)
EDIT: ik wilde een
. toevoegen
restorecon -Rv /var/lib/mysql/database_namecommando na het kopiëren van de database om alle selinux-contexten te krijgen
zoals ze zouden moeten zijn, ook al verwijderen we ze uit de
database bijna onmiddellijk, maar als alternatief zou je gewoon kunnen toevoegen
de –archive of -a optie voor de twee cp commando’s, dus ja eigenlijk de
archiefoptie verkort dit: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 mariadbnaar alleen het volgende waarvan ik denk dat het beter is en het houdt de selinux
context die is ingesteld voor de reeds gemaakte tabel.cp -a innodb_table2.frm innodb_table.frm cp -a innodb_table2.ibd innodb_table.ibd systemctl restart mariadbIk heb de bovenstaande langere lijst met commando’s vervangen door de kortere lijst
die nog kan worden ingekort met een *
Antwoord 7, autoriteit 3%
Het verwijderen/verplaatsen van tablename.ibd werkte zeker niet voor mij.
Hoe ik het heb opgelost
Aangezien ik de beschadigde en niet-bestaande tabel wilde verwijderen, nam ik een back-up van de andere tabellen door naar phpmyadmin->database->export->geselecteerde tabellen te gaan om back-up->export(as . sql).
Daarna selecteerde ik het databasepictogram naast de databasenaam en liet ik het vallen. Nieuwe databank aangemaakt. Selecteer uw nieuwe database->import-> Selecteer het bestand dat u eerder hebt gedownload->klik op importeren. Nu heb ik mijn oude werktabellen en heb ik de beschadigde tafel verwijderd. Nu maak ik gewoon de tabel die de fout veroorzaakte.
Waarschijnlijk had ik een eerdere back-up van de beschadigde tabel.
Antwoord 8, autoriteit 2%
Ik kreeg dezelfde fout toen ik het op wampserver uitvoerde terwijl ik probeerde een gebruikerstabel te maken. Ik vond een user.ibd-bestand en nadat ik dit bestand had verwijderd, voerde ik de migratieopdracht opnieuw uit en het werkte. Het bestand op mijn Windows-computer bevond zich in wamp/bin/mysql/mysql5.6.12/data/myproject.
Antwoord 9, autoriteit 2%
Oplossing
De eenvoudigere optie is echter deze: herstart MySQL en voer dezelfde vier stappen als volgt uit:
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
Op deze manier kwamen de tabelruimte-id in de datadictionary en het bestand overeen; dus het importeren van de tabelruimte is gelukt.
Dit kan u meer vertrouwen geven in het omgaan met enkele van de InnoDB-‘gotcha’s’ tijdens het herstelproces of zelfs bestandsoverdrachten.
Antwoord 10
Dit probleem meerdere keren gehad. Als je een grote database hebt en back-up/restore wilt vermijden (met toegevoegde ontbrekende tabel), probeer dan een paar keer heen en weer:
DROP TABLE my_table;
ALTER TABLE my_table DISCARD TABLESPACE;
-en-
rm my_table.ibd (wees zonder corresponderende my_table.frm) in /var/lib/mysql/my_db/ directory
-en toen-
MAAK TABEL ALS DIE NIET BESTAAT my_table(…)
Antwoord 11
Dit zijn de oplossingsstappen:
- maak een back-up van uw database (structuur met drop-optie en gegevens)
- stop mysql engine-service
- verwijder de databasedirectory handmatig vanuit mysql/data
- start mysql-engine
- maak een nieuwe database met een andere naam dan uw beschadigde database
- maak een enkele tabel met de naam van de beschadigde tabel in de nieuwe database (dit is het geheim). en het is beter om de tabel met exact dezelfde structuur te maken.
- hernoem de database naar de oude corrupte database
- herstel uw back-up en uw tabel zal goed werken.
Antwoord 12
Deze fout treedt op wanneer u bepaalde functies onderbreekt. Zoals het uitvoeren van de onderstaande query met een onjuiste externe sleutel.
set foreign_key_checks=0
Antwoord 13
Had precies hetzelfde probleem; Ik had [email protected]toegevoegd (na eerder 5.5 te hebben gehad).
De standaardinstellingen voor het zetten van 5.6 zijn innodb_file_per_table=1terwijl ze in 5.5 innodb_file_per_table=0zijn.
Uw bestaande ibdata1-bestand (de gecombineerde innodb-gegevens) bevat nog steeds verwijzingen naar de tabellen die u probeert te maken/verwijderen. Verander innodb_file_per_tableterug naar 0, of verwijder het ibdata1-gegevensbestand (hiermee verlies je al je gegevens, dus zorg ervoor dat je het eerst mysqldump hebt of al een .sql-dump hebt).
De andere brouw [email protected]standaard die me beet, was het ontbreken van een poort, dus netwerken was standaard naar unix-sockets, en de mysql-client bleef rapporteren:
ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32
Ik heb <string>--port=3306</string>toegevoegd aan de .plistarray, maar je zou ook port=3306in uw my.cnf
Voer brew services stop [email protected]uit, breng uw wijzigingen aan en brew services start [email protected]
Antwoord 14
Ik had hetzelfde probleem. Ik heb de databasenaam hernoemd & importeer het. Dan werkt het.
Maak het simpel:
Gewoon De naam van de database wijzigen. Dat is het.
Het probleem is dat de bestaande databasenaam enkele vermeldingen in uw map heeft. Dat is het probleem. Of u moet al die gerelateerde vermeldingen verwijderen of
Maak het eenvoudig om de database te hernoemen
Antwoord 15
Als je de tabelruimte probeert te verwijderen, kun je andere fouten krijgen. Bij mij kreeg ik de volgende foutmelding:
DROP TABLESPACE `tablename`
Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP'
Mijn oplossing was om de database te laten vallen. Hiermee worden alle bijbehorende tabelruimten verwijderd en kunt u de tabellen opnieuw maken.
Antwoord 16
Als je een andere server hebt met een goede versie van dezelfde tabel, kun je een kopie maken (tabel_kopie), en de tabel_kopie overbrengen naar de probleemserver. Verwijder vervolgens de probleemtabel en hernoem table_copy naar tabel.
Antwoord 17
Voor mij hielp het om gewoon naar de map MYSQL DATA te gaan onder /var/lib/mysql/{db_name}(linux) en het bestand {table_name}.ibdneer te zetten was hetzelfde als de mapnaam.
Antwoord 18
Ik verwijder alleen mijn oude DB die zich in mijn localhost bevindt, rechtstreeks van wamp, stop alle services, ga naar wamp/bin/mysql/mysql[versie]/data en ik vond de DB met problemen, ik verwijder deze en begin opnieuw wamp alle services, maak opnieuw uw database en het is klaar, nu kunt u uw tabellen importeren,
Antwoord 19
De manier waarop ik dit probleem heb kunnen ‘oplossen’ is behoorlijk vervelend, maar er is een script dat dit afhandelt.
In wezen hebt u de bestanden ibdata1en ib_logfile*nodig om te verdwijnen (ze bevatten onder andere de toewijzingen van externe sleutels). De enige veiligemanier om dit te doen is door al uw databases te exporteren, mysql te stoppen, de bestanden te verwijderen, mysql te starten en vervolgens de bestanden te importeren.
Het script dat dit probleem helpt oplossen is https://github.com/uberhacker/shrink-ibdata1 , ook al is het aangegeven doel van dit script anders, het losthet probleem op.
Antwoord 20
U kunt de volgende query uitvoeren als een mysql root-gebruiker
drop tablespace `tableName`
Antwoord 21
De enige manier waarop het voor mij werkte was:
- Maak een vergelijkbare tabel
- Kopieer de .frm- en .idb-bestanden van de nieuwe vergelijkbare tabel naar de naam van de corrupte tabel.
- Permissies herstellen
- Herstart MariaDB
- Laat de corrupte tabel vallen
Antwoord 22
Bedankt #DangerDave, dit heeft mijn probleem met Magento 2 opgelost, en zo heb ik het gedaan
Ik heb een vps
root@myvps [~]# cd /var/lib/mysql/mydatabasename/
root@myvps [~]# ls
controleer op tabellen zonder .frm fie (alleen .idb) en verwijder ze,
rm customer_grid_flat.ibd
Het systeem zal de tabellen opnieuw genereren na het uitvoeren van de opdracht index:reindex
Antwoord 23
In het geval van Homebrew is de map voor gegevensbestanden /usr/local/var/mysql
om te zien welk my.cnf-bestand hier wordt gebruikt, zijn de zoeklocaties uit mijn omgeving
/etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf
Dus om deze fout op te ruimen heb ik het volgende gedaan
mysqladmin -u root shutdown
rm /usr/local/var/mysql/<dbname>/problemtablename.ibd
Opmerking: in mijn geval gaf ik niet om de gegevens omdat het dev-configuratie is, waarschijnlijk omdat ik mijn laptop heb hersteld met timemachine
Antwoord 24
Als je dit probleem hebt en je hebt geen andere optie, verander dan de engine in een andere engine zoals ‘myisam’, probeer dan de tabel te maken.
disclaimer:
het is niet het geldige antwoord, omdat u mogelijk beperkingen met externe sleutels hebt die niet worden ondersteund door een andere opslagengine. Elke storage-engine heeft zijn eigen specialiteit om gegevens op te slaan en te openen, deze punten moeten ook in aanmerking worden genomen.
Antwoord 25
VERWIJDER de tabelruimte vóór het IMPORTEREN
Ik heb hetzelfde probleem, de oplossing staat hieronder
-
Eerst moet je je databasenaam neerzetten. als je database niet wordt verwijderd, heb je me laten stromen.
Voor een Windows-systeem zal uw map zijn:
C:/xampp/mysql/data/yourdabasefolder verwijder “yourdabasefolder” -
Je moet opnieuw een nieuwe database maken en je oude sql-bestand importeren. Het zal werken
Bedankt
Antwoord 26
Ik moest mijn MySQL-gegevensdirectory vinden:
TOEN VARIABELEN WAAR Variable_Name LIKE “%dir”
Verwijder vervolgens die database geforceerd:
sudo rm -rf