[Ubuntu] Herstellen 'table doesn't exist' foutmelding

[CH4OS]

Ik heb een Ubuntu 13.04 server draaien binnen een guest op mijn VMWare server.
In één nacht tijd, is daarbij de (virtuele) disk volgeraakt met binary logs van MySQL.
Deze zijn opgeschoond en er is inderdaad weer ruimte in overvloed.

Echter heeft degene die het voor me heeft 'opgelost' daarbij óók de ib_-logfiles en ibdata1 files verwijderd, nadat hij InnoDB support had uitgeschakeld, niet wetende dat ik databases heb waar tabellen in zitten die InnoDB gebruiken.

Je voelt hem al: geen back-up (terwijl dat eigenlijk wel zou moeten, ik weet het, bespaar me dus díe preek, daar heb ik nu gewoon niets aan), wel databases die nodig zijn of nu slechts gedeeltelijk beschikbaar zijn.
Zo bestaan er volgens MySQL bepaalde tabellen niet meer in databases, die met een show tables dan weer wel zichtbaar zijn. Is er een manier om dit te herstellen? Er zijn nu wel weer nieuwe ib_-logfiles en een ibdata01 file, maar dat zijn dus nieuw gegenereerde bestanden, die bijvoorbeeld diverse tabellen uit 2 WordPress databases, een RoundCube database en een Spotweb database niet 'herkend'.

Middels Google vind ik vooral how to's die dan eigenlijk gewoon een export en een import maken, maar omdat er bij mij best wel een aantal databases nu naar de knoppen zijn, denk ik dat mij dat veel te veel tijd gaat kosten (ik moet zeggen dat ik op een dergelijke manier ook nog nooit een DB heb gerestored).
De data an sich is namelijk niet weg, de .FRM en de .MYI bestanden zijn namelijk nog gewoon in /var/lib/DATABASE/ te vinden.

Hebben jullie een idee hoe ik dit nu nog kan herstellen of ben ik gewoon de Sjaak?

Doe ik bijvoorbeeld de volgende query:

SQL:

select `username` from users

in mijn Spotweb database, dan krijg ik de melding

ERROR 1146 (42S02): Table 'spotweb.users' doesn't exist

, terwijl de file er wel degelijk staat volgens locate. Ook overigens als ik show tables doe, zie regel 26:

code:

mysql> show tables;
+--------------------+
| Tables_in_spotweb  |
+--------------------+
| cache              |
| commentsfull       |
| commentsposted     |
| commentsxover      |
| filtercounts       |
| filters            |
| grouppermissions   |
| nntp               |
| notifications      |
| permaudit          |
| reportsposted      |
| reportsxover       |
| securitygroups     |
| sessions           |
| settings           |
| spots              |
| spotsfull          |
| spotsposted        |
| spotstatelist      |
| spotteridblacklist |
| usergroups         |
| users              |
| usersettings       |
+--------------------+
23 rows in set (0.00 sec)

Ik heb ook geprobeerd, om de ownership aan te passen, die stond voor veel op root:root (waarom geen idee) en heb dit aangepast naar mysql:mysql, daarna MySQL herstart en dat heeft helaas ook niet gewerkt.

EDIT:
Ik heb gisteren ook de 6 verschillende innodb_force_recovery modi in my.cnf geprobeerd, maar mocht ook niet baten.

[ Voor 34% gewijzigd door CH4OS op 01-08-2013 09:07 ]

[marti-n]

Helaas geen oplossing, maar dit is wel iets wat ik ga volgen, ben hier namelijk vorige week zelf ook me bezig geweest. De tabellen bestaan als fysieke bestanden, worden ook gevonden met een locate, maar zijn onmogelijk in (in mijn geval) phpmyadmin te krijgen en veroorzaken dus een table does not exist.

Uiteindelijk ben ik maar gewoon opnieuw begonnen, stond geen belangrijke data in en het systeem was toe aan een schone install. Maar dat is natuurlijk geen echte oplossing in dit geval.

[Kees]

Heb je innodb_file_per_table aanstaan of niet? Verder zegt de aanwezigheid van myisam bestanden niet zoveel over welke data wel en niet weg is.

Anyway, leesvoer:
http://www.mysqlperforman...recovery-deleted-ibdata1/ << maar helaas heb je je mysql al gerestart...
http://www.mysqlperforman...cting-orphaned-ibd-files/ << als je files_per_table hebt
https://launchpad.net/percona-data-recovery-tool-for-innodb << Eventueel kun je daar nog wat mee.

Als je geen files_per_table hebt, en een restart hebt gedaan, dan is er een erg grote kans dat die data nu gewoon weg is.

[ Voor 11% gewijzigd door Kees op 01-08-2013 09:52 ]

[CH4OS]

Ik heb bij de databases die InnoDB gebruiken per tabel wel een .FRM file. Zover ik Google begrijp, zijn dat dan toch files per table? Dan laatste twee URLs eens even bekijken, ben nu op het werk en kan remote niet bij die machine.

[Kees]

CptChaos schreef op donderdag 01 augustus 2013 @ 09:57:
Ik heb bij de databases die InnoDB gebruiken per tabel wel een .FRM file. Zover ik Google begrijp, zijn dat dan toch files per table? Dan laatste twee URLs eens even bekijken, ben nu op het werk en kan remote niet bij die machine.

Nee, een innodb_file_per_table geeft je een .frm en een .ibd:
.ibd = Innodb Data + index + Definitie
.frm = Format / Table Definition
.MYD = MyISAM data
.MYI = MyISAM index

Een innodb table heeft zijn data, definitie en indexes in ibdata1 staan en een .frm file (waardoor je hem nu dus soms nog ziet) en een myisam table heeft een .frm, .MYD en een .MYI. Die myisam tables moet je nog gewoon bij kunnen komen.

[CH4OS]

De .ibd files zijn ook verwijderd door de opschoningsactie.
Ik kan ook inderdaad bij de MyISAM tabellen, die files zijn dan ook nog gewoon aanwezig.

[ Voor 43% gewijzigd door CH4OS op 01-08-2013 10:07 ]

[GlowMouse]

Dan kun je de .frm-files weggooien om van de 'table doesn't exist' melding af te komen, maar je data krijg je niet meer terug.

[CH4OS]

Niet het antwoord wat ik hoopte, maar ben er wel mee geholpen. Ik weet voldoende, dankjewel!