Eșecul de recuperare
Aici discutăm despre modul de recuperare a datelor după:
- eroare de sistem de operare
- întreruperea alimentării
- eșecul sistemului de fișiere
- defecțiuni hardware (hard disk, placa de bază.)
Vom folosi versiunea 4.1.8 a serverului MySQL. Presupunem că datele sunt stocate utilizând motorul InnoDB, care suportă tranzacțiile și blocarea automată a erorilor. De asemenea, vom presupune că serverul MySQL este încărcat în momentul accidentului. În caz contrar, nu este necesară recuperarea.
Cazurile 1) și 2)
În aceste cazuri, putem presupune că discul cu date MySQL este disponibil după repornirea sistemului de operare. În timpul repornirii consistența datelor în fișiere InnoDB din cauza prăbușirii, dar InnoDB citește protocoalele sale, există o listă a deținuților (ale căror rezultate nu sunt resetate la un fișier) completat și tranzacții în așteptare, sub formă de rulouri automat incomplet, și resetează în rezultatele dosarului tranzacției finalizate. Informațiile despre procesul de recuperare după o eroare sunt transmise utilizatorului prin jurnalul de erori MySQL. Extras din protocol:
Cazurile 3) și 4)
În aceste cazuri, credem că un disc cu date MySQL nu este disponibil după o repornire de sistem; Deoarece un număr de blocuri ale unui disc de date nu mai pot fi citite, MySQL nu poate porni cu succes. Ei bine, am formatat discul sau instalați unul nou și este timpul să restaurați datele din backup. ah, trebuie să avem grijă de ei la timp! Să facem un pas înapoi și să elaborăm o politică de salvare a datelor.
Politica de backup al datelor
Știm cu toții că crearea periodică a copiilor de rezervă (rollbacks) ar trebui planificată în avans. Rularele complete (snapshot-uri de date la un moment dat) sunt create folosind mai multe instrumente MySQL. Hot Backup InnoDB oferă o redirecționare fizică (non-blocantă) fizică (copii de fișiere de date) online. mysqldump oferă o revizuire logică online, pe care o vom discuta mai târziu în discuție. exemplu:
Acest lucru creează o revigorare a tuturor tabelelor InnoDB din toate bazele de date, fără a interfera cu operațiile curente de citire / scriere a acestor tabele. Conținutul fișierului .sql este setul de instrucțiuni SQL INSERT. (Să presupunem că este o revigorare completă la ora 13 dimineața duminică, când încărcarea serverului este scăzută.)
Este necesar să faceți backup-uri complete, dar nu întotdeauna convenabil. Ele generează fișiere de redirecționare mari și necesită timp. Ele nu sunt optime în sensul că stochează din nou datele care nu s-au schimbat de la crearea întregului ansamblu de redare anterioară. Este mai optimă pentru modificările înapoi (deși acestea salvează timpul de revenire din cauza timpului de recuperare).
Pentru a face răsturnări de modificări, trebuie să le rezolvăm. Pentru ca serverul să stocheze informații despre modificările aduse fișierului în timp ce modifică datele, acesta trebuie pornit cu opțiunea --log-bin. Apoi, fiecare instrucțiune SQL care modifică datele va fi scrisă într-un fișier (pe care îl numim "Protocolul binar MySQL"). Să examinăm conținutul directorului de date al serverului MySQL, care rulează câteva zile în modul -log-bin. Vom vedea aici protocoalele binare MySQL:
De fiecare dată când reporniți, serverul MySQL oprește scrierea fișierului curent de protocol binar, creează unul nou și din acel moment fișierul nou va deveni unul curent (cel în care este scrisă înregistrarea). Acest lucru se poate face manual prin comanda SQL FLUSH LOGS. Fișierul index conține o listă a tuturor protocoalelor binare stocate în director (se utilizează pentru replicare).
Aceste protocoale binare MySQL reflectă schimbările. Să modificăm ușor comportamentul mysqldump, astfel încât protocolul binar să se comute atunci când este creată copia de rezervă completă; să vedem ce nume este atribuit noului protocol binar actual:
Acum vedem fișierul gbichot2-bin.007 din directorul de date. Fișierul nostru .sql conține următoarele rânduri:
Aceasta înseamnă că toate modificările de date, reflectate în protocoalele binare, sunt mai vechi decât gbichot2-bin.007. sunt prezente în fișierul .sql. și toate modificările de date reflectate în fișierul gbichot2-bin.007 sau mai nou nu se găsesc în fișierul .sql. Luni, la ora 1 după-amiază, pentru a reveni la modificări, introduceți comanda mysqladmin -flush-logs. care va crea gbichot2-bin.008. Toate modificările făcute între orele 13:00 duminică, când a fost efectuată o revigorare completă și 1 oră de luni sunt reflectate în fișierul gbichot2-bin.007. Copiați acest fișier prețios într-o locație de siguranță securizată (bandă, mașină de rezervă, DVD, etc.).
Marți, la ora 13, vom relua din nou log-urile mysqladmin -flush. Toate modificările făcute între 1 dimineața luni și 1 după-amiaza zilei de marți se reflectă în fișierul gbichot2-bin.008. De asemenea, îl copiem la locul de depozitare în siguranță.
Aceste protocoale binare MySQL ocupă spațiu pe disc; din când în când trebuie să-l eliberăm. Este o idee bună să eliminați protocoalele binare pe care nu le veți avea nevoie, adică, după crearea unei copii de rezervă complete:
Înapoi pentru a restabili din copii de rezervă
Deci, există un refuz, spune miercuri, la ora 8 dimineața. Am reluat ultima revoluție completă pe care o avem, duminică, ora 13. Deoarece este doar un set de instrucțiuni SQL, procesul de recuperare este foarte simplu:
Datele noastre se află în starea în care se aflau duminică, ora 13. Pentru a recupera răsturnările, trebuie doar să le eliminați din locația sigură și să faceți următoarele:
Acum datele noastre se află în statul marți, ora 13. Încă mai pierdem schimbările din acest moment până în momentul eșecului. Pentru a nu-i piardă, era necesar ca serverul MySQL menține jurnalele binare pe dispozitiv (RAID, discuri SAN.) Altele decât cel în care se stochează fișierele de date, iar apoi aceste jurnale nu au fost pe disc a eșuat. Dacă am avut grijă de ea (acum o facem, promitem!), Am avea fișier gbichot2-bin.009. și l-am restabili, iar datele noastre ar fi la fel ca în momentul prăbușirii (nimic nu ar fi fost pierdut). Chiar am putea să acționăm și mai flexibil; dacă declarația DROP DATABASE a fost executată în mod eronat în loc de o eroare. am putea revocăm modificările de la gbichot2-bin.009 în momentul în care precede imediat DROP DATABASE, astfel încât datele noastre au ajuns la starea imediat anterioară execuției lui! De exemplu, dacă ai ști că declarația în eroare declanșată în jurul valorii de 7:30, el va face revenirea la starea de la ora 7 dimineața (rezervă de 30 de minute):
Acest lucru este puțin inexact (pierdeți o schimbare de aproximativ o jumătate de oră), dar este destul de potrivit într-o serie de cazuri; în acele cazuri în care într-adevăr nu își pot permite să piardă nimic, doriți să rulați mysqlbinlog chiar înainte de drop database. Există mai multe moduri de a face acest lucru, iată unul:
Ștergem toate liniile care încep cu DROP DATABASE, salvați a_temp_file.sql și executați
MySQL A dormi liniștit: Nota 1: în viața reală ar necesita includerea opțiunilor --user și --password (și specificați corect numele de utilizator și parola) la programele mysqldump si MySQL, astfel încât acestea să poată stabili o conexiune la serverul MySQL. Nota 2: Eliminarea buștenilor binare cu MySQL mysqldump -delete-master-busteni pot fi periculoase dacă serverul dvs. este un server master replicare, vezi „Replication“, explică ceea ce ar trebui să fie verificată înainte de a șterge jurnalele binare MySQL.
Articole similare