Onderwerp: Databases kunnen niet gebackuped of gedumpt worden

Op een directadmin server krijg ik de volgende foutmelding in de backup log:

Error while backing up database "databasenaam"
mysqldump error output: mysqldump: Got error: 1146: Table 'databasenaam.s95l0_onepage_config' doesn't exist when using LOCK TABLES

in SQL error file zie ik alleen maar de volgende foutmeldingen:

141021 3:41:02 [ERROR] Cannot find or open table databasenaam/s95l0_onepage_config from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.5/...eshooting.html
how you can resolve the problem.

Het probleem is nu dat de Directadmin backup elke dag failed op de databases.
Ik heb mysqlchecks, auto repairs enz uitgevoerd => heeft niet geholpen
Ik heb myisamchecks uitgevoerd => heeft niet geholpen
verwijderen van ibdata, ib_logfiles, pid en err bestand en nieuwe aanmaken heeft ook niet het gewenste effect gehad.
Op internet het een en ander opgezocht natuurlijk en ook het enige geprobeerd, maar helaas is het er niet beter op geworden.


Nu heb ik wel een vermoeden hoe dit allemaal zo is gekomen.
De server had geen vrije ruimte meer waardoor er niets meer werkte, ik heb wat ruimte vrij gemaakt en de server herstart. De webpagina's konden hierna alsnog geen correcte verbinding maken met de database.
Ik heb een backup teruggezet van een klein pakketje met en mysql database, waarna deze wel goed werkte.
Vervolgens is besloten om een backup terug te zetten van alle hosting hostingpakketten. Dit was op dat moment de snelste manier om de boel online te krijgen.

Ik heb zelf onvoldoende diepgaande mysql kennis en tijd om dit probleem binnen korte tijd op te lossen.
Welke MySQL guru ziet dit als een uitdaging en kan mij hierbij helpen?

Heb je al een analyse/repair gedaan op de betreffende tabellen/database?

Ik heb de volgende mysqlcheck uitgevoerd:
mysqlcheck -u da_admin -p --all-databases --tables --auto-repair --optimize --extended --force

en ook deze:
myisamchk -r *.MYI

Dit zou de databases en commando's moeten herstellen, of niet?

Een MYISAM check op InnoDB werkt niet echt.

Als het alleen die ene tabel betreft, dan move de betreffende .frm even naar een plek buiten de database directory en restore dan die betreffende tabel uit een werkende backup. (of als de inhoud niet spannend was, maak de tabel dan gewoon opnieuw aan).

Wat er niet meer is... kan niet meer herstelt worden natuurlijk. Met wat truukjes kun je eventueel die tabeldefinitie wel herstellen op basis van een losse .frm, maar je records krijg je daar niet mee terug.

De server had geen vrije ruimte meer waardoor er niets meer werkte, ik heb wat ruimte vrij gemaakt en de server herstart.

De foutmelding die je krijgt kan je oplossen door het betreffende bestand te verwijderen (verplaatsen).
http://dev.mysql.com/doc/refman/5.5/...-datadict.html
http://serverfault.com/questions/449...-tablename-doe

MySQL ondersteund meerdere storage engines (ieder met zijn/haar eigen beperkingen).
Dus is het belangrijk bij het zoeken naar informatie te kijken voor welke storage engine er word gebruikt.

InnoDB heeft gelukkig wel enige vorm van recovery (zij het met wat hulp), bij MyISAM was het over en uit.

Een recovery in MyISAM zonder voldoende ruimte gaat fout. Punt.
Bij een recovery (of optimize) maakt MySQL een nieuwe tabel aan met de zelfde structuur, en zal dan de data proberen te kopiëren, als dat om welke reden dan ook verkeerd gaat (te weinig diskruimte) raakt MySQL in paniek en zal deze de nieuwe en oude tabel ONHERROEPELIJK VERWIJDEREN!

Doe een recovery in MyISAM ALLEEN ALS ER EEN GOEDE BACK-UP IS en voldoende schrijfruimte!!

Dank je voor jullie reacties. Zoals aangegeven is MySql niet mijn kennis gebied en heb geen tijd om hier in te duiken.
Ik heb het druk zat. Wil iemand dit tegen betaling fiksen?

Het betreft een VPS Directadmin server icm Centos 6.x.
Er is geen recente goede backup aanwezig van de databases. laatste goede backup voor dit gebeuren is wel aanwezig en dateert van 01-10-2014.
Wel is er de mogelijkheid om een Clone en snapshot te maken van deze server (hypervisor laag is VMWare).