Sziasztok,
Egy áramszünet után a Raspberry Pi-ra (Raspbian / Stretch) telepített MariaDB nem akar elindulni (Nextcloudhoz van (volt...) használva). A file-rendszer ext4 - ami elvileg naplózó, de valahogy mégis megsérültek a dolgok (nem értek hozzá, gondolom az adatbázis file-ok lehetnek inkonzisztensek akkor is, ha maguk a file-ok a file-rendszerben nem serültek)
Próbáltam több dolgot, első körben leállítottam meg elindítottam a service-t, meg újraindítottam az gépet, keresgéltem Google-lel, nem találtam megoldást.
Az egész adatbázist (/var/lib/mysql/*) átraktam PC-re (Debian / Stretch), ott is ugyanaz történik.
Vissza lehet ezt még hozni vagy újra kell csinálnom az adatbázist a Nextcloud alá?
Van valakinek ötlete, hogy mit lenne még érdemes megpróbálni mielőtt újratelepítem?
Köszi
Sok probálkozás és file másolgatás után (már nem emlékszem, hogy melyik file-ok lettek végül felülírva, az ibdata1 illetve a nextcloud könyvtár biztosan az eredeti maradt) a megoldás az lett, hogy elindítottam egy "mysqld --innodb-force-recovery=5"-öt, amivel vegül nem abortált a szerver és csináltam egy dumpot a nextcloud adatbázisáról, majd töröltem mindent a /var/lib/mysql könyvtárból, utána pedig mysqld --initialize. Visszamásoltam a mysql könyvtárat (tehát /var/lib/mysql/mysql), csináltam egy nextcloud adatbázist és visszatöltöttem a dumpból az adatokat. Most működik a rendszer.
Hozzászólások
Hat, epp a minap tapasztaltuk kollegakkal hogy az rpi egy ilyen "mentsuk le a file valtoztatasat, majd inditsuk ujra a rendszert" jellegu dologgal sem birkozik meg. Azaz reboot elott azt hiszi hogy a file rendben van (ugyanaz mint amit modositottunk/lememtettunk), de ujrainditas utan mar igy nem, es visszaall az eredeti allapotra. Semmi db, semmi komolyabb tranzakciot igenylo cucc, csak mezei text data (sh-szkript).
Szoval minel gyorsabban egy dd-s mentést javallanék, oszt bizva bizni kell hogy hatha utana mar nem lesz problema. Persze offline fsck, db ellenorzes, stb utan tennem csak vissza az rpi-be az uj kartyat.
Nem SD-kartya, abban már rég nem bízok (meg lassú is), USB-n van rákötve egy SSD, persze ettől függetlenül lehetnek korrupt file-ok, megprobálom majd leállitani és egy normál gépen megnézni, hogy mit mond az fsck.
/sza2
Digital? Every idiot can count to one - Bob Widlar
A logban hivatkozott doksiban levőket próbáltad?
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Ha a recoverys linkre gondolsz, azt néztem, de én úgy látom, azok a dolgok csak akkor működnek, ha elindul az adatbázis, viszont bármilyen mode-ot állítok be, rövid idő után (pár másodperc) "Segmentation fault" a vége.
/sza2
Digital? Every idiot can count to one - Bob Widlar
mysqlrepair?
Ha jól értem, ez is csak akkor működik, ha elindult az adatbázis :-(
/sza2
Digital? Every idiot can count to one - Bob Widlar
A /var/lib/mysql/aria_log.00000002 fájl megvan? Ha nincs, én létrehoznám, adnék neki mysql:mysql tulajt, 0660 jogot, mint a többinek, aztán újraindítanám.
Ha nem segít, törölném a /var/lib/mysql/aria_log_control -t és a többi aria_log* fájlt is, majd restart.
Ha ez sem, segít, akkor a: mysqld --initialize létrehoz egy üres, de működőképes /var/lib/mysql/ mappát, ebből kiszedném az aria* fájlokat, ezzel felülírva a sérültet.
Nem ismerem mélyebben az aria storage engine működését. Lehet, ez valami binlog szerű dolog, és a sérülése esetén ezért nem tud elindulni az aria.
Ha egyik sem meny, akkor a működő üres /var/lib/mysql/ mappába egyesével próbálnám meg visszamásolni az adatábzisok fájljait, és utána egy mysqlrepair-ral javítani, hátha így megy.
Valamint az aria_chk is segíthet, hátha mond valami okosat.
Köszi. Vegül kiderült, hogy az ibdata1 file volt ami nem tetszett neki. Az volt a gond, hogy anelkül hiába látta a táblákat, nem tudtam selecteket indítani, mindig panaszkodott. Fent leírtam, hogy mi lett végül a megoldas.
/sza2
Digital? Every idiot can count to one - Bob Widlar
https://www.thegeekstuff.com/2011/12/mysqlcheck/
Ez nekem egyszer bejött Zentyal alatt sérült meg az adatbázis
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
A mysqlcheck elvileg ugyanaz mint a mysqlrepair. A leírásban szó esik a myisamchk parancsról is, megprobáltam azzal is (az működik magukon a file-okon is, nem kell hogy fusson a szerver), de lefuttatva nem mond semmi hibát.
/sza2
Digital? Every idiot can count to one - Bob Widlar
elindítottam egy "mysqld --innodb-force-recovery=5"-öt, amivel vegül nem abortált a szerver
VS
viszont bármilyen mode-ot állítok be, rövid idő után (pár másodperc) "Segmentation fault" a vége.
Legközelebb legyél figyelmesebb mert a félrevezető információk miatt egyáltalán nem, vagy csak sokára kapsz segítséget.
http://blackbird.si/mysql-corrupted-innodb-tables-recovery-step-by-step…
OK, a kep nem teljes, emiatt tenyleg felrevezeto. Ez elejen amikor elkezdtem, valoban minden mode-ra seg fault lett. Az igazsaghoz hozzatartozik, hogy rengeteg dologgal probalkoztam, torolgettem / visszaraktam tobbszor kulonbozo file-okat, kozben is volt --initialize parszor, oszinten, nem emlekszem 100%-ban az egesz folyamatra (kulonosen, hogy kisebb nagyobb megszakitasokkal volt tarkitva, mert nem tudtam egesz nap ezzel foglalkozni).
/sza2
Digital? Every idiot can count to one - Bob Widlar