Mysql 4

4.4.6.9. Cum se repară mesele

În această secțiune, este luată în considerare numai utilizarea myisamchk pe tabelele MyISAM (extensii .MYI și .MYD). Dacă tabelele ISAM (extensii .ISM și .ISD) sunt utilizate în sistem, este necesar să se utilizeze isamchk.







Începând cu versiunea MySQL 3.23.14 poate repara tabele MyISAM folosind comanda repair TABLE (a se vedea secțiunea 4.4.5, „Sintaxa REPAIR TABLE»).

Simptomele coruperii tabelului includ întreruperi neașteptate în executarea interogării și apariția următoarelor erori:

tbl_name.frm este blocat împotriva schimbării (fișierul este blocat pentru modificări)

Nu se poate găsi tbl_name.MYI fișier (ERRCODE: ###) (nu pot găsi tbl_name.MYI fișier (eroare: ###))

Sfârșitul neașteptat al fișierului (Dintr-o dată, sfârșitul)

Fișierul de înregistrare este blocat (Fișierul de înregistrare este corupt)

A apărut o eroare ### de la managerul de tabelă (Eroare primită ### din descriptorul de tabel). Pentru mai multe informații despre eroare, puteți rula perror ###. Cele mai multe ori, următoarele erori indică problemele cu tabelul:

Rețineți că eroarea 135 - "Nu mai există loc în fișierul de înregistrare", nu poate fi repusă doar prin efectuarea unei reparații. În acest caz, utilizați următoarea comandă:

În alte cazuri, ar trebui să reparați mesele. myisamchk poate detecta și rezolva de obicei majoritatea problemelor.

Procesul de reparare include până la patru etape descrise aici. Înainte de a începe repararea, trebuie să rulați cd-ul în directorul bazei de date și să verificați drepturile de acces la fișierele de tabelă. Fișierele ar trebui să poată fi citite de utilizatorul Unix, în numele căruia mysqld rulează. (precum și efectuarea de reparații, deoarece trebuie să acceseze fișierele verificate). Dacă este necesară modificarea fișierelor, verificatorul trebuie să aibă și acces la scriere.

Dacă utilizați o versiune de MySQL 3.23.16 și de mai sus, utilizați CHECK și REPARAREA comenzi pentru a verifica și tabele de reparații MyISAM, puteți (și ar trebui) (a se vedea secțiunea 4.4.4, „Sintaxa VERIFICARE TABLE» și a se vedea secțiunea 4.4.5, „Sintaxa REPAIR TABLE» ).

Cazurile în care comenzile de mai sus nu funcționează sau este de dorit să se utilizeze caracteristicile avansate prezentate în isamchk / myisamchk. sunt discutate în secțiunea următoare.

Dacă intenționați să reparați masa din linia de comandă, trebuie mai întâi să opriți serverul. Trebuie remarcat faptul că atunci când rulează shutdown mysqladmin de pe un server mysqld la distanță, acesta va funcționa pentru o perioadă de timp după terminarea mysqladmin. până când toate cererile sunt oprite și toate cheile sunt aruncate.







Etapa 1: Verificarea meselor

Rulați myisamchk * .MYI sau, dacă aveți timp, myisamchk -e * .MYI. Utilizați opțiunea -s (mod silențios) pentru a suprima informațiile inutile.

Dacă mysqld este oprit, utilizați opțiunea -update-state pentru a spune myisamchk să marcheze tabelele ca fiind "checked".

Reparații ar trebui să fie doar acele tabele pentru care myisamchk a emis erori. Pentru astfel de tabele, mergeți la pasul 2.

Dacă în timpul testului sunt primite erori ciudate (similare cu cele din memorie) sau dacă myisamchk este prăbușit, treceți la pasul 3.

Etapa 2: Repararea ușoară în siguranță

Notă: dacă există dorința de a accelera reparația, se recomandă să adăugați: -O sort_buffer = # -O key_buffer = # (unde # este aproximativ 1/4 din memoria disponibilă) în toate comenzile isamchk / myisamchk.

Mai întâi, încercați să rulați myisamchk -r -q tbl_name (-r -q înseamnă "modul de recuperare rapidă"). Aceasta va încerca să repare fișierul index fără modificarea fișierului de date. Dacă fișierul de date conține tot ce aveți nevoie, iar legăturile de la distanță indică pozițiile corecte din fișierul de date, comanda ar trebui să dea rezultatul și tabelul va fi fixat. Mergeți la repararea tabelului următor. În caz contrar, procedați în felul următor:

Faceți o copie de siguranță a fișierului de date.

Utilizați myisamchk -r tbl_name (-r înseamnă "modul de recuperare"). În acest caz, înregistrările incorecte și șterse vor fi șterse din fișierul de date și fișierul index va fi recreat.

Dacă în etapa anterioară problema nu poate fi rezolvată, utilizați myisamchk --safe-recover tbl_name. În modul de recuperare sigură, se utilizează metoda veche de recuperare, care gestionează unele cazuri care nu sunt posibile pentru modul normal de remediere (dar această metodă funcționează mai lent).

Dacă erorile ciudate (similare cu cele din memorie) sau myisamchk sunt terminate anormal în timpul testului, treceți la pasul 3.

Etapa 3: reparații complexe

Înainte de această etapă, se întâmplă numai dacă primul bloc 16K din fișierul index este distrus sau conține informații incorecte sau atunci când lipsește fișierul index. În acest caz, trebuie să creați un nou fișier index. Este necesar să efectuați următoarele acțiuni:

Deplasați fișierul de date într-un loc sigur.

Utilizați fișierul cu descrierea tabelului pentru a crea fișiere noi (goale) - date și index:

Dacă versiunea SQL pe care o utilizați nu are TRUNCATE TABLE. apoi se utilizează DELETE FROM table_name.

Copiați fișierul de date vechi în locul nou creat (a face mutarea fișierelor vechi înapoi în loc nou inoportun, deoarece în fișierul vechi poate fi necesară din nou, dacă ceva nu merge bine).

Mergeți înapoi la etapa 2. myisamchk -r -q ar trebui să funcționeze acum (dar nu repetați fără sfârșit).

În ceea ce privește MySQL 4.0.2, atunci puteți utiliza REPAIR. USE_FRM. care efectuează automat toate aceste proceduri.

Etapa 4: reparații foarte complicate

Până în această etapă, veți ajunge numai dacă orice altceva este corupt și fișierul descriptiv. Acest lucru nu trebuie să se întâmple, deoarece fișierul descriptiv nu se modifică după crearea tabelului. Faceți următoarele:

Restabiliți fișierul descriere dintr-o copie de rezervă și du-te la etapa 3. De asemenea, puteți restaura fișierul index și du-te înapoi la etapa 2. În acest din urmă caz, ar trebui să înceapă cu -r myisamchk.

Dacă nu există nicio copie de siguranță, dar știi exact cum a fost creată tabela, atunci o copie a tabelului este creată într-o altă bază de date. Noul fișier de date este șters, apoi fișierul descriptiv cu fișierul index este mutat dintr-o altă bază de date la cea deteriorată. În acest fel, veți obține un fișier descriptiv nou și un fișier index, fără a afecta fișierul de date. Reveniți la pasul 2 cu o încercare de a recrea fișierul index.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: