Reparera korrupta MySQL-tabeller!?

När det inte går att få till reparation via klienterna(Jag kör mysqlcc) så är det konsolprogrammet myisamchk som gäller när jag fått motsvarande problem på skrivintensiva tabeller i samband med "oplanerade" avstängningar.

Tänk på att mitt fall så är det MyISAM tabeller. Kolla vad Du har för några innan Du går vidare. Och glöm inte att en säkerhetskopia(stäng tjänsten/demonen innan, skall dock inte ha någon påverkan i ditt fall) på filerna INNAN Du påbörjar processen.

Minns inte vart jag gömde "fusklappen" men Google gav mig detta och det verkar vara det jag körde:
https://dev.mysql.com/doc/mysql-backup-excerpt/5.7/en/myisam-...

Då börjar vi med några frågor:

1. Vilken version utav MySQL servern kördes filerna på när allt fungerade?
2. Vilket operativsystem körde MySQL servern på när allt fungerade?
3. Var där någon känslig klartext information i filerna?
4. Hur stora är alla filer sammanlagt?
5. Om Du t.ex. kör maximal komprimering med ZIP, 7z, Bz m.fl. på dessa filer, hur stor blir filen som kommer ut?
6. Kan Du tänka dig att skicka filerna över Internet till en främmande person?

Punkt 5 är valbar(inget krav).

Så du har aldrig kört några backuper på dina databaser?
Har aldrig försökt återställa en trasig databas / tabeller eftersom jag alltid kört schemalagda backuber / cronjobs.

Men kan ju testa!

MariaDB har jag inte meckat med. Har meckat med MySQL sedan år 2002 på Windows, Red Hat, CentOS, FreeBSD och OpenBSD. Men vad jag förstår så är det samma gäng som skapade MySQL och förfarandet skall vara exakt eller snarlikt.

RAR går bra.

Skriv vilka tabeller det är som kassa i en liten textfil och lägg den i RAR filen.

Kolla om WeTransfer har stöd utan mottagarens e-postadress.
Annars lägg dig själv på en alternativ e-postadress som mottagare.

Skicka sedan över en WeTransfer länk via PM, eller lägg den publikt om Du vill ha så många som möjligt som hjälper dig(först till kvarn vinner ).

Borde kunna börja kika på det om ett par timmar och ha ett svar innan morgon då jag har lite att göra just nu.

Vi håller tummarna på att där ens finns någon data i dom skadade filerna, specifikt i myd filerna men även frm. Om frm är totalt trasigt så kan man skapa nya frm filer förutsatt att Du kommer ihåg exakt hur dom skadade tabellerna såg ut.

En annan fråga:
Vad är det för typ av lösning som databasen användes till? Forum, ekonomi, support m.m. ? Egenutvecklat eller publikt? Om publikt, vad heter lösningen?

Hur gjordes säkerhetskopiorna?
Om Du bara körde filkopiering rakt av så har Du frm, myd och myi filerna någonstans, och dessa bör vara friska.
Eller körde Du via en schemaläggare som körde mysqlkonsolprogrammet?

Har Du tabellstrukturen i huvudet(exakt som den skall vara) som Du kan lägga in i tråden för wf_ladder? För där finns hopp för den men strukturfilen(FRM) accepteras inte.

Annars verkar det bara vara wf_user_league som jag fått igång som verkar ha 367248 poster.

wf_season_score.MYD som är störst är tyvärr tom . Bara luft i den. Indexfilen till den verkar ha data men det är MYD filen som innehåller faktisk data.

Och övriga går inte att fixa med dom verktyg som jag känner till.

SQL filer är lättare för ögat. Om dom innehåller binär data så kan man urskilja den enklare än att jobba med ögat mot MYD, MYI, FRM filer.

Så kan Du lägga upp dom så kikar jag på det med.

Din CREATE fungerade. Vet inte hur många rader som förväntades i den tabellen, men 91 rader syns hos mig.

Om det är ett medlemsregister så är den filen felaktigt ihopsatt utav filsystemet, eftersom det borde vara läsbart. Här på forumet ser det ut som en binär BLOB.

Här är i alla fall resultatet:
https://we.tl/t-8qUGeBLS2w

Där finns även en SQL fil, vilket är det korrekta sättet att importera en säkerhetskopia. Om Du föredrar att lägga filerna direkt själv på rätt plats så finns dom även med i länken.

Hade Du någon BLOB i någon tabell som Du inte skickat över?

Om ja, då kan man prova sig på dom på samma vis som jag gjorde med dom andra.

Om nej, så måste Du i så fall läsa på om det binära formatet för MYD filer. Och därefter antingen manuellt eller skriva ett program som letar efter markörer och plockar ut data och lägger dom på rätt ställe. Eller kolla om någon redan har byggt ett sådant program och i så fall prova det.

När filsystemet är hackat och malet så blir det väldigt manuellt.

Det var innehållet i länken som jag lämnade instruktioner för. Den SQL fil som finns i ZIP-filen i länken skall gå att importera. Den länken innehåller vad jag har kunnat få ihop med det Du hade i din länk.

Om Du inte hade något BLOB fält i tabellerna så är det Du visat ifrån SQL filen inte data i ett BLOB fält, utan helt enkelt binär information som filsystemet ser på den platsen där det borde finnas troligtvis klar-text-data. Detta är i så fall ett typiskt tecken på ett filsystem som pekar till platser där det inte riktigt är den data man förväntar sig, ett trasslat filsystem.

Om Du kan med egna ögon se data som borde vara där så kan man försöka "klippa" ut delar ifrån den som inte skall vara där och få ihop den för hand, eftersom själva strukturen i en SQL fil är ren klar-text medan datan kan variera mellan klartext och binär beroende på fälttyperna som fanns i tabellen.

Men om Du inte kan se med egna ögon data som borde vara där, så är den filen tyvärr körd.

Om det verkligen var en SQL fil som var tänkt som säkerhetskopia så kan man "klippa" ihop den för att försöka få tillgång till så mycket data som möjligt.

Bättre något än inget.

Om Du vill att jag skall kika på det så kan Du lägga upp den någonstans och skicka uppgifterna för att komma åt den via meddelandefunktionen här på SweClockers.