Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
MySQL - naprawa bazy...
342 views
Skip to first unread message
fReLuZ
Sep 26, 2011, 1:17:35 PM9/26/11
to
A wiec po wylaczeniu pradu baza danych mysql nie startuje tylko sypie
takimi bledami:
110926 12:26:47 InnoDB: Page checksum 3900496246, prior-to-4.0.14-form
checksum 2151297201
InnoDB: stored checksum 1877316168, prior-to-4.0.14-form stored checksum
1279365543
InnoDB: Page lsn 259 1166847273, low 4 bytes of lsn at page end 1166958975
InnoDB: Page number (if stored to page already) 111899,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 98
InnoDB: (index history_1 of table zabbix/history)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 111899.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
No i poprostu padl index jakis.. no i teraz jaka jest procedura naprawy
takiej bazy krok po kroku?
Chyba cos takiego:
1. podniesc baze w trynie emergency (jak?)
2. zlokalizowac index.. tez zabardzo nie wiem...
3. wykasowac index
4. podniesc baze danych normalnie
5. skreowac index
No chyba, ze ktos ma inna prostsza procedure?
takimi bledami:
110926 12:26:47 InnoDB: Page checksum 3900496246, prior-to-4.0.14-form
checksum 2151297201
InnoDB: stored checksum 1877316168, prior-to-4.0.14-form stored checksum
1279365543
InnoDB: Page lsn 259 1166847273, low 4 bytes of lsn at page end 1166958975
InnoDB: Page number (if stored to page already) 111899,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 98
InnoDB: (index history_1 of table zabbix/history)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 111899.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
No i poprostu padl index jakis.. no i teraz jaka jest procedura naprawy
takiej bazy krok po kroku?
Chyba cos takiego:
1. podniesc baze w trynie emergency (jak?)
2. zlokalizowac index.. tez zabardzo nie wiem...
3. wykasowac index
4. podniesc baze danych normalnie
5. skreowac index
No chyba, ze ktos ma inna prostsza procedure?
NKAB -
Sep 27, 2011, 2:17:55 AM9/27/11
to
fReLuZ <fre...@ibt.com.pl> napisaďż˝(a):
Je�li to napewno tylko indeksy to najpro�ciej:
- renejmujesz uszkodzony plik indeksowy danej tabeli
- kopiujesz (powielasz) dowolny plik indeksowy z innej tabeli
(ja robi� pust� tabelk� z w�a�ciwymi indeksami)
- renejmujesz skopiowany plik na nazw� uszkodzonego orygina�u
- uruchamiasz, i powinno byďż˝ juďż˝ ok.
W przypadku uszkodzonych struktur nie pr�bowa�em ale my�l�,
�e te� tak mo�na.
Andrzej.
--
Wys�ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Ronald Kuczek
Sep 27, 2011, 5:17:06 AM9/27/11
to
On 09/26/2011 07:17 PM, fReLuZ wrote:
> InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
> InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
> No i poprostu padl index jakis.. no i teraz jaka jest procedura naprawy
> takiej bazy krok po kroku?
Sam log podpowiada, że masz zrobić to, co napisano tutaj:
> takiej bazy krok po kroku?
http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Raz mi się zdarzyła podobna sytuacja postąpiłem tak:
1. W my.cnf innodb_force_recovery=4
2. Zrobiłem kopię katalogu mysql na zimno.
3. Uruchomiłem serwer.
4. W logu znalazłem informację która tabela jest uszkodzona.
5. Ponieważ akurat na niej mi nie zależało zrobiłem drop, wykomentowałem
wpis w p.1 i zrestartowałem serwer. Jeśli to ważna tabela można
spróbować repair a później dump, drop i ponowny create.
Pozdrawiam
Rony
jahu
Sep 27, 2011, 9:59:12 AM9/27/11
to
Ronald Kuczek pisze, W dniu 2011-09-27 11:17:
trybów innodb_force_recovery pozwala na dostęp do danych w trybie
read-only co pozwala na zrobienie pełnego backupu bazy. Następnie można
taką bazę odtworzyć i na 100% mamy w pełni sprawną bazę (jeśli
uszkodzeniu nie uległa zawartość tabel, a tylko indeksy).
Warto pamiętać, że backup mysql to zupełnie inny rodzaj backupu od tego
znanego z MSSQL.
--
jahu
> On 09/26/2011 07:17 PM, fReLuZ wrote:
>> InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
>> No i poprostu padl index jakis.. no i teraz jaka jest procedura naprawy
>> takiej bazy krok po kroku?
>
> Sam log podpowiada, że masz zrobić to, co napisano tutaj:
>
> http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
>
> Raz mi się zdarzyła podobna sytuacja postąpiłem tak:
>
> 1. W my.cnf innodb_force_recovery=4
Autorowi też sugeruję przejrzenie powyższej dokumentacji. Któryś z
>> InnoDB: See also http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
>> No i poprostu padl index jakis.. no i teraz jaka jest procedura naprawy
>> takiej bazy krok po kroku?
>
> Sam log podpowiada, że masz zrobić to, co napisano tutaj:
>
> http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
>
> Raz mi się zdarzyła podobna sytuacja postąpiłem tak:
>
> 1. W my.cnf innodb_force_recovery=4
trybów innodb_force_recovery pozwala na dostęp do danych w trybie
read-only co pozwala na zrobienie pełnego backupu bazy. Następnie można
taką bazę odtworzyć i na 100% mamy w pełni sprawną bazę (jeśli
uszkodzeniu nie uległa zawartość tabel, a tylko indeksy).
Warto pamiętać, że backup mysql to zupełnie inny rodzaj backupu od tego
znanego z MSSQL.
--
jahu
Ronald Kuczek
Sep 27, 2011, 10:35:50 AM9/27/11
to
On 09/27/2011 03:59 PM, jahu wrote:
> Autorowi też sugeruję przejrzenie powyższej dokumentacji. Któryś z
> trybów innodb_force_recovery pozwala na dostęp do danych w trybie
> read-only co pozwala na zrobienie pełnego backupu bazy. Następnie można
> taką bazę odtworzyć i na 100% mamy w pełni sprawną bazę (jeśli
> uszkodzeniu nie uległa zawartość tabel, a tylko indeksy).
>
> Warto pamiętać, że backup mysql to zupełnie inny rodzaj backupu od tego
> znanego z MSSQL.
Swoją drogą wciąż nie mogę przestać się dziwić awariom, które spotykają
> Autorowi też sugeruję przejrzenie powyższej dokumentacji. Któryś z
> trybów innodb_force_recovery pozwala na dostęp do danych w trybie
> read-only co pozwala na zrobienie pełnego backupu bazy. Następnie można
> taką bazę odtworzyć i na 100% mamy w pełni sprawną bazę (jeśli
> uszkodzeniu nie uległa zawartość tabel, a tylko indeksy).
>
> Warto pamiętać, że backup mysql to zupełnie inny rodzaj backupu od tego
> znanego z MSSQL.
firmy poniekąd na ich własne życzenie. Wyłączenie prądu może się zdarzyć
a firmę powinno być stać na zakup UPS-a.
Pozdrawiam
Rony
fReLuZ
Sep 28, 2011, 1:57:20 AM9/28/11
to
W dniu 2011-09-27 08:17, NKAB - pisze:
> fReLuZ<fre...@ibt.com.pl> napisał(a):> Jeśli to napewno tylko indeksy to najprościej:
> - renejmujesz uszkodzony plik indeksowy danej tabeli
> - kopiujesz (powielasz) dowolny plik indeksowy z innej tabeli
> (ja robię pustą tabelkę z właściwymi indeksami)
> fReLuZ<fre...@ibt.com.pl> napisał(a):
> - renejmujesz uszkodzony plik indeksowy danej tabeli
> - kopiujesz (powielasz) dowolny plik indeksowy z innej tabeli
No wlasnie a jak wyeksportowac bierzace indexy z tej tabeli?
NKAB -
Sep 28, 2011, 5:36:22 AM9/28/11
to
fReLuZ <fre...@ibt.com.pl> napisał(a):
> No wlasnie a jak wyeksportowac bierzace indexy z tej tabeli?
Tak naprawdę to same powinny się odtworzyć, wystarczy
odtworzyć plik indeksowy z roboczej tabeli, chodzi tu
o nieuszkodzony plik, dlatego ja robię pustą tabelkę
z takimi samymi polami data i polami ideksowymi
i plik indeksowy z tej roboczej tabelki kopiuję do tej uszkodzonej.
czyli na dysku widzimy pliki:
mysql5.1.53
|
--- data
|
----TBL- pliki: t1.frm
t1.myd
t1.myi
t2.frm
t2.myd
t2.myi
uszkodzona jest t2.myi lub t2.frm i te właśnie trzeba
zastąpić więc zmieniamy nazwę pliku na t2.myixxxxxx
i z tej t3 roboczej kopiujemy właśnie t3.myi i t3.frm,
zmieniamy nazwę na t2.myi i t2.frm, uruchamiamy i indeksy
powinny się same odtworzyć.
Najpierw pytanie czy tabela z danymi nie jest uszkodzona,
bo jeśli tak jest, to odtworzenie indeksów będzie niemożliwe.
Wówczas najpierw trzeba doprowadzić do porządku dane
a indeksy same się utworzą.
Z danymi to już trudniejsza sprawa. Naprawienie to lokalizacja
obszaru uszkodzonego ręcznie jadąc sekwencyjnie po rekordach
(bez użycia indeksów) najpierw od góry do dołu a potem od dołu
do góry. Tam gdzie jest uszkodzenie tam się wywali.
Znając numery krańcowych rekordów od-do usuwasz ten obszar
najpierw dropem a potem trunkejtem a brakujące (z usuniętej częsci)
rekordy dodajesz z wczesniejszych kopii.
Wpisujesz pola indeksowe i po uruchomieniu już się
powinny same odtworzyć.
Jeśli chodzi o tzw klucze indeksowe jak je znasz to:
ADD PRIMARY KEY (`Id`,`p34`,`p31`(15),`p32`(15)).
Każdy dobry program ma jednak opcję tworzenia plików indeksowych
więc ta wiedza nie jest potrzebna.
Przy naprawianiu najlepiej jednak korzystać z rozwiązań
systemowych naprawy bazy, tak jak radzą koledzy.
Andrzej.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
> No wlasnie a jak wyeksportowac bierzace indexy z tej tabeli?
odtworzyć plik indeksowy z roboczej tabeli, chodzi tu
o nieuszkodzony plik, dlatego ja robię pustą tabelkę
z takimi samymi polami data i polami ideksowymi
i plik indeksowy z tej roboczej tabelki kopiuję do tej uszkodzonej.
czyli na dysku widzimy pliki:
mysql5.1.53
|
--- data
|
----TBL- pliki: t1.frm
t1.myd
t1.myi
t2.frm
t2.myd
t2.myi
uszkodzona jest t2.myi lub t2.frm i te właśnie trzeba
zastąpić więc zmieniamy nazwę pliku na t2.myixxxxxx
i z tej t3 roboczej kopiujemy właśnie t3.myi i t3.frm,
zmieniamy nazwę na t2.myi i t2.frm, uruchamiamy i indeksy
powinny się same odtworzyć.
Najpierw pytanie czy tabela z danymi nie jest uszkodzona,
bo jeśli tak jest, to odtworzenie indeksów będzie niemożliwe.
Wówczas najpierw trzeba doprowadzić do porządku dane
a indeksy same się utworzą.
Z danymi to już trudniejsza sprawa. Naprawienie to lokalizacja
obszaru uszkodzonego ręcznie jadąc sekwencyjnie po rekordach
(bez użycia indeksów) najpierw od góry do dołu a potem od dołu
do góry. Tam gdzie jest uszkodzenie tam się wywali.
Znając numery krańcowych rekordów od-do usuwasz ten obszar
najpierw dropem a potem trunkejtem a brakujące (z usuniętej częsci)
rekordy dodajesz z wczesniejszych kopii.
Wpisujesz pola indeksowe i po uruchomieniu już się
powinny same odtworzyć.
Jeśli chodzi o tzw klucze indeksowe jak je znasz to:
ADD PRIMARY KEY (`Id`,`p34`,`p31`(15),`p32`(15)).
Każdy dobry program ma jednak opcję tworzenia plików indeksowych
więc ta wiedza nie jest potrzebna.
Przy naprawianiu najlepiej jednak korzystać z rozwiązań
systemowych naprawy bazy, tak jak radzą koledzy.
Andrzej.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Ronald Kuczek
Sep 28, 2011, 5:54:07 AM9/28/11
to
On 09/28/2011 11:36 AM, NKAB - wrote:
> czyli na dysku widzimy pliki:
>
> mysql5.1.53
> |
> --- data
> |
> ----TBL- pliki: t1.frm
> t1.myd
> t1.myi
> t2.frm
> t2.myd
> t2.myi
>
Po pierwsze problem dotyczył tabel InnoDB a nie MyISAM a po drugie
> czyli na dysku widzimy pliki:
>
> mysql5.1.53
> |
> --- data
> |
> ----TBL- pliki: t1.frm
> t1.myd
> t1.myi
> t2.frm
> t2.myd
> t2.myi
>
żonglowanie plikami bazy danych serwera takiego jak MySQL czy dowolny
inny to szukanie guza, to nie jest Paradox czy dBase ! Nieprofesjonalne,
potrafi dać nieprzewidziane efekty słowem - niedopuszczalne.
Pozdrawiam
Rony
NKAB -
Sep 28, 2011, 6:10:32 AM9/28/11
to
>Po pierwsze problem dotyczył tabel InnoDB a nie MyISAM a po drugie
>żonglowanie plikami bazy danych serwera takiego jak MySQL czy dowolny
>inny to szukanie guza, to nie jest Paradox czy dBase ! Nieprofesjonalne,
>potrafi dać nieprzewidziane efekty słowem - niedopuszczalne.
Rzeczywiście przeoczyłem InnoDB.
>żonglowanie plikami bazy danych serwera takiego jak MySQL czy dowolny
>inny to szukanie guza, to nie jest Paradox czy dBase ! Nieprofesjonalne,
>potrafi dać nieprzewidziane efekty słowem - niedopuszczalne.
Tylko raz miałem przypadek gdzie nie mogłem naprawić
systemem a ten mój sposób przywrócił mi tabelę.
Moje tabele na szczęście są dość małe, przy dużych
byłbym bardziej ostrożniejszy.
jerzy
Oct 8, 2011, 12:02:37 PM10/8/11
to
> Swoją drogą wciąż nie mogę przestać się dziwić awariom, które spotykają
> firmy poniekąd na ich własne życzenie. Wyłączenie prądu może się zdarzyć
> a firmę powinno być stać na zakup UPS-a.
dłużej, mają awarię. Dobry UPS (taki na godziny) kosztuje worek siana
Jacek Czerwinski
Oct 8, 2011, 1:01:13 PM10/8/11
to
W dniu 2011-10-08 18:02, jerzy pisze:
>
>> Swoj� drog� wci�� nie mog� przesta� si� dziwi� awariom, kt�re spotykaj�
>> firmy poniek�d na ich w�asne �yczenie. Wy��czenie pr�du mo�e si� zdarzy�
>> a firmďż˝ powinno byďż˝ staďż˝ na zakup UPS-a.
>
> Zwykle maj� UPSa ale takiego 10 minutowego wi�c kiedy pr�du nie ma
> d�u�ej, maj� awari�. Dobry UPS (taki na godziny) kosztuje worek siana
Ewentualnie kabelek kt�ry w miar� bezpiecznie wy��czy maszyn�, kosztuje 5z�.
>
>> Swoj� drog� wci�� nie mog� przesta� si� dziwi� awariom, kt�re spotykaj�
>> firmy poniek�d na ich w�asne �yczenie. Wy��czenie pr�du mo�e si� zdarzy�
>> a firmďż˝ powinno byďż˝ staďż˝ na zakup UPS-a.
>
> Zwykle maj� UPSa ale takiego 10 minutowego wi�c kiedy pr�du nie ma
> d�u�ej, maj� awari�. Dobry UPS (taki na godziny) kosztuje worek siana
Ewentualnie kabelek kt�ry w miar� bezpiecznie wy��czy maszyn�, kosztuje 5z�.
0 new messages