MySQL jak odzyskać dane po błędzie w mysql-bin.X?

[damian.1923 0]

Witam

 

Proszę o wskazówkę, jak mogę odzyskać dane z bazy po uszkodzeniu logu binarnego.

(nie mam backupu)

 

mysql -u root -p:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

 

fragment /var/log/mysql/error.log:

120904 10:59:00 InnoDB: Starting shutdown...

120904 11:28:29 [Note] Plugin 'FEDERATED' is disabled.

InnoDB: The log sequence number in ibdata files does not match

InnoDB: the log sequence number in the ib_logfiles!

120904 11:28:29 InnoDB: Database was not shut down normally!

InnoDB: Starting crash recovery.

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Restoring possible half-written data pages from the doublewrite

InnoDB: buffer...

InnoDB: Transaction 0 381994154 was in the XA prepared state.

InnoDB: 1 transaction(s) which must be rolled back or cleaned up

InnoDB: in total 0 row operations to undo

InnoDB: Trx id counter is 0 381995008

InnoDB: Last MySQL binlog file position 0 8440536, file name ./mysql-bin.001388

InnoDB: Starting in background the rollback of uncommitted transactions

120904 11:28:29 InnoDB: Rollback of non-prepared transactions completed

120904 11:28:29 InnoDB: Started; log sequence number 6 3806000415

^G/usr/sbin/mysqld: File './mysql-bin.001388' not found (Errcode: 2)

120904 11:28:29 [ERROR] Failed to open log (file './mysql-bin.001388', errno 2)

120904 11:28:29 [ERROR] Could not open log file

120904 11:28:29 [ERROR] Can't init tc log

120904 11:28:29 [ERROR] Aborting

120904 11:28:29 InnoDB: Starting shutdown...

 

na forach znalazłem metodę:

echo '' >/var/db/mysql/mysql-bin.index

jak przypuszczam, to spowoduje utratę danych?

 

czy istnieje jakiś sposób na naprawę pliku bez utraty bazy?

[Gość patrys]

Używasz tych logów binarnych ? Jest tam jakaś replikacja ? Padła baza danych ?

Pliki *.index zawierają nazwy plików binarnych, serwer mysql nie przeszukuje dysku za plikami, a opiera się na tym indexie.

Gdy wykonasz to "echo" serwer zgubi wątek, bo nie będzie wiedział od którego pliku binarnego zacząć.

Więc jeżeli nie używasz binarnych logów, zrób backup ich na wszelki wypadek i możesz czyścić pozostałości po tych logach.

Wtedy serwer MySQL się podniesie

[damian.1923 0]

bardzo dziękuję za pomoc,

wyczyściłem indeks, baza podniosła się wraz z danymi > SUPER

 

PS: replikacji nie było, obawiałem się że wyczyszczenie logów usunie dane z bazy, a nie mogłem się z nią połączyć żeby zrobić backup.

[Gość patrys]

To tylko logi które wykorzystuje się głównie pod replikacje baz danych, jeżeli jej nie używasz to dla wydajności możesz wyłączyć ich tworzenie.

[regdos 1848]

A do ROLLBACKów przy transakcjach nie są też przypadkiem wykorzystywane?

[beliq 442]

A do ROLLBACKów przy transakcjach nie są też przypadkiem wykorzystywane?

.

Są, gdyż MySQL domyślnie synchronizuje dziennik InnoDB z dziennikiem binarnym,

aczkolwiek wydaje mi się, że w przypadku bazy lokalnej,

która nie jest replikowana, możesz to spokojnie wyłączyć.

InnoDB posiada swoje własne dzienniki w przestrzeni

tabel dt. aktualnych transakcji, kopie rekordów, które zostały zmienione i czekają na commit,

i jeszcze kilka różnych pierdół, których nie idzie zapamiętać.

Jeśli robisz rollback, InnoDB nie potrzebuje do tego binlog'a - sam sobie z tym poradzi.

W przypadku crash'a powinien zachować się tak samo, gdyż wszystkie zapisane

połowicznie dane znajdzie u siebie w buforze zapisu, który również jest flush'owany na dysk.

[Gość patrys]

Dokładnie dziennik binarny nie jest wykorzystywany przez InnoDB, jedynie do odzyskiwania danych ręcznie do określonego punktu w czasie i mając kopie z danego punktu można przywrócić via roll forward zmiany które zostały przeprowadzone po.

Bo sam rollback jak napisał poprzednik jest w mechanizmie InnoDB i generalnie te binlogi to stosuję się w replikacji, a mało w sumie kto je męczy do odzyskiwania danych.