Ehkäpä työnnät koodin, joka rikkoo välimuistin, joka palvelee tietoja miljoonille ihmisille,
Ehkä päivität sovelluksen ja päätät puhaltaa pois tiedot, joita ei ole varmuuskopioitu,
Tai ehkä työnnät muutoksen, joka "toimii koneellasi", mutta letkuttaa kokonaan lähteen ohjausvaraston.

Ja muita esimerkkejä on paljon. Olen varma, että voit nopeasti nimetä viisi muuta itse.

Olen sitoutunut (pun tarkoittamani, tavallaan) oman osuuteni kaikesta yllä olevasta, mutta yhdestä asiasta, jonka näen tiloissamme työskenteleviltä ihmisiltä.

Toisin sanoen ne, jotka työskentelevät tietokannan tukemien web-sovellusten parissa – on puutteellinen ymmärrys tietokannan organisoinnista tiedostojärjestelmätasolla ja siitä, kuinka on mahdollista rekonstruoida tietoja, vaikka sinulla ei olisikaan normaalia varmuuskopiota, josta toimia.

Tässä viestissä aion sukeltaa syvälle MySQL-tietokantaorganisaatioon tiedostojärjestelmätasolla, kuinka voit palauttaa tietoja siitä verrattuna varmuuskopiotiedostoon, jos joudut sellaiseen tilanteeseen, ja tarjoamaan viitteitä (tai kirjanmerkkejä) tarvitset niitä.

MySQL-tietojen rekonstruointi

Selvyyden vuoksi aion puhua MySQL-tietokannasta, joka toimii *nix-pohjaisen käyttöjärjestelmän muunnelmassa (joten tarkastelet Linux- tai macOS-jakelua).

Tiedostojen sijainnit (jotka käsittelen hetken) vaihtelevat Windows-pohjaisissa järjestelmissä, mutta sinun on etsittävä ne MySQL-oppaasta tai vastaavasta resurssista.

Asia on: Ennen kuin menet liian pitkälle tähän artikkeliin, tiedä missä tiedostot sijaitsevat käyttöjärjestelmässäsi. Jos esimerkiksi käytät macOS:ää ja löydät sen todennäköisesti hakemistosta /usr/local/mysql/data.

Käytän mieluummin Homebrew’ta, joten MySQL-tietokantani ovat /usr/local/var/mysql . Ja kuten yllä näet, huomaat tiedostoja, joilla on sama nimi kuin järjestelmässäsi olevilla tietokannoilla. .

Miten tietokannat järjestetään

Pintatasolla se näyttää melko yksinkertaiselta. Mutta jos aiot avata hakemiston yllä mainitulla tavalla, huomaat, että suuri osa näkemästäsi on hakemistoja – ei tiedostoja sinänsä – jotka sisältävät lisätietoja.

Jos syvennät yhteen hakemistoista, näet useita tiedostoja:

Näitä tiedostoja ovat seuraavat:

MAAILMAN
MINUN MINÄ
FRM
IBD

Ja jokainen näistä tiedostotyypeistä on olemassa jokaiselle tietokannan taulukolle.

Katsotaanpa näitä siis tarkemmin saadaksemme paremman käsityksen siitä, mistä tietokanta koostuu.

1 Tietokanta on joukko tiedostoja

Yleisesti ottaen useimmat meistä tietävät, että MySQL on relaatiotietokanta ja jokainen tietokanta koostuu joukosta taulukoita, jotka kaikki tallentavat erityyppistä tietoa (ja monet taulukot liittyvät jollain tavalla toisiinsa, vaikka se olisi vain arvo yksi sarake).

Mutta tämä viesti ei koske tietokannan relaatiota eikä sitä, kuinka voimme suorittaa kyselyitä sitä vastaan. (Jos olet kiinnostunut, kokeile sitä – se kaikki perustuu monikkolaskeluun .)

Sen sijaan tässä on kyse sen ymmärtämisestä, että jokaisessa taulukossa on joukko tiedostoja, jotka viittaavat kunkin taulukon sisältämiin tietoihin. Ja

2 Tiedostotyyppien ymmärtäminen

Koska jokainen tietokannan taulukko koostuu yllä olevista tiedostotyypeistä, tarkastellaan yksittäistä tiedostotyyppiä ja määritetään sitten rooli jokaisessa taulukossa (ja lopulta kuinka tämä vaikuttaa koko tietokantaan).

MYD. Tämä tiedosto sisältää tiedot, jotka on tallennettu tietokantataulukon riveille. Tämä tiedosto liittyy läheisesti FRM-tiedostoon.
FRM. Tämä tiedosto sisältää taulukkomuotoiset tiedot (joka sisältää esimerkiksi tietokannan kunkin sarakkeen rakenteen, sen sisältämien tietojen tyypin ja niin edelleen).
MYI. Tämä on tietokantahakemisto. Jos käytät MyISAM-tietokantaa (jota useimmat meistä käyttävät tällä hetkellä InnoDB:tä), sinulla on tämä tiedosto. Lisäksi tiedoissa on tietoa siitä, onko tiedot suljettu kunnolla vai ei. Pidä tätä tiedostona itse taulukon eheydestä. Ei siinä olevaa tietoa, ei sen muotoa.
IBD. Tämä on tiedostotyyppi, joka liittyy InnoDB-tietokantataulukoihin (joten et ehkä näe tätä tietokannan hakemistossa). Jos kuitenkin teet niin, on tärkeää tietää, että InnoDB-pohjaiset tietokannat tallentavat tietoja kustakin tämän tiedoston taulukosta.

Yllä olevissa tiedoissa on kaksi muuta tutkimisen arvoista aihetta.

MyISAM
InnoDB

Ennen kuin tarkastelet kaikkia näitä, huomaa, että MyISAM ja InnoDB ovat niin sanottuja tallennusmoottoreita. Se kuulostaa hienolta, mutta se liittyy siihen, kuinka tietokantaohjelmisto hallitsee tietojen luomista, lukemista, päivittämistä ja poistamista.

MyISAM & InnoDB: Mitä eroa on?

Jokainen näistä tallennuskoneista eroaa siitä, miten ne käsittelevät tapahtumia, lukitsemista, palautuksia ja hakuja. Niille, jotka ovat tietokannan ylläpitäjiä, kaikki edellä mainitut ovat tuttuja (mutta et todennäköisesti myöskään lue tätä 🙃).

Ei tietenkään tämän tyyppinen moottori.

Meille muille meillä on tämä:

Tapahtumat tapahtuvat aina, kun vähintään kahta käskyä, kuten SELECT ja UPDATE tai INSERT ja DELETE, tai mitä tahansa näiden kahden (tai useamman) yhdistelmää käytetään yhdessä toistensa kanssa. Joten jos valitsisit tiedot ja POISTAisit sitten tulokset, sinulla olisi tapahtuma.
- MyISAM ei tue tapahtumia. Tämä tarkoittaa, että jos "tapahtuma" keskeytyy, se vaikuttaa kaikkiin toiminnan aikana käsiteltyihin tietoihin. Täytyy sanoa, että tätä ei käytetä.
- InnoDB puolestaan takaa, että muutoksia ei tehdä taulukkoon ennen kuin tapahtuma on suoritettu loppuun. Toisin sanoen muutoksia ei sitouduta tietokantaan.
Jokaisen varastomoottorin lukitus vaihtelee pöytätasolla tai rivitasolla. Aina kun suoritat kyselyä taulukkoa vastaan, MyISAM lukitsee koko taulukon, kunnes prosessi on valmis. InnoDB puolestaan lukitsee vain ne rivit, joihin tämä vaikuttaa. Tämä on tärkeä ero, koska se tarkoittaa, että voit jatkaa toimintaasi taulukossa, mutta ei samoilla riveillä, aina kun käytät InnoDB:tä.
Palautukset eivät ole mahdollisia MyISAMissa. Tämä tarkoittaa, että kun muutos on tehty, se on tehty. InnoDB tarjoaa palautuksia. Oletetaan, että teet muutoksen taulukkoon, teit vahingossa jotain, jota et aikonut tehdä, ja voit palauttaa sen edelliseen tilaan. Tätä ei kuitenkaan pidä sekoittaa varmuuskopioon. Se on enemmän kuin tapahtuman "kumoa"-toiminto.
Haku, erityisesti siinä, miten rakennamme tietokantaamme, on avainasemassa, kun järjestämme tietoja tietokantojemme sisällä. Yksinkertaisesti sanottuna InnoDB tukee FULLTEXT- indeksointia (MySQL 5.6.4:stä alkaen). Mutta jos isäntäsi tai palveluntarjoajasi ei salli FULLTEXT-indeksejä, väitän, että se ei ole dealbreaker.

Kun otetaan huomioon kaikki yllä olevat tiedot, jokaisen on nähtävä, että InnoDB-tallennusmoottorin edut ovat paljon suuremmat kuin MyISAM-tallennusmoottorin edut, varsinkin jos haluat käyttää MySQL-versiota, joka on vähintään yhtä suuri kuin 5.6.4.

3 Tietokannan luominen uudelleen

Oletetaan tässä vaiheessa, että tiedät, että sinulla on pääsy tietokannan muodostaviin tiedostoihin käyttöjärjestelmästä.

Ehkä se on edellinen varmuuskopio, ehkä pystyt paikantamaan tiedostot levyltä tai ehkä voit hakea ne jollain muulla tavalla – ja sinun on palautettava tietokanta aiempaan kohtaan.

1 Älä tee sitä tuotannossa

Ennen kuin teet mitään, luo tyhjä tietokanta paikalliselle koneellesi ja yritä sitten tuoda tiedot. Mutta jälleen kerran, tämä ei ole kuin pelkkä tietokannan käyttöliittymä SQL-tiedoston tuomiseen.

Luo sen sijaan hakemisto, joka vastaa luotavan tietokannan nimeä. Tässä viestissä käytän esimerkkiä trunkdev (koska tässä työskentelen käyttämällä uusinta versiota WordPress trunkista ).

2 Varmuuskopioi olemassa oleva tietokanta

Varmuuskopioi seuraavaksi olemassa oleva tietokanta niin paljon kuin mahdollista – olipa kyseessä tietokannan käyttöliittymä tai tiedostojen kopio. Kopioi sen jälkeen tiedostot lähdesijainnista luomaasi hakemistoon.

Sinun pitäisi tässä vaiheessa pystyä lataamaan valitsemasi tietokantakäyttöliittymä ja nähdä juuri kopioimiesi tietokantatiedostojen tiedot. Tämä riippuu siitä, että tiedostot eivät ole vioittuneet ja tietokantapalvelin käynnissä.

3 Älä asenna muita ohjelmistoja

Huomaa, että tässä vaiheessa en yrittäisi asentaa siihen muita ohjelmistoja, kuten WordPressiä tai muita tietoja. Työskentele sen sijaan suoraan tietojen kanssa. Olettaen, että se näkyy käyttöliittymässäsi, tee oikea varmuuskopio tai vie tiedosto SQL-tiedostoksi, jotta voit helpommin palauttaa tiedot tulevaisuudessa.

Jotkut käyttöliittymät antavat sinulle mahdollisuuden viedä vain tiettyjä taulukoita. Tässä tapauksessa varmuuskopioi kaikki. Joidenkin tietokantojen osalta tämä kestää kauan; muille, ei niin paljon. Kaikki riippuu projektin koosta.

4 Työskentele tietojen kanssa

Tässä vaiheessa sinun pitäisi pystyä käsittelemään tietokantaa käyttöliittymän tai SQL:n avulla. Jos et ole mukava tai edes varma kuinka tehdä tämä, keskustele jonkun kanssa, joka voi olla uskomattoman herkkä (teillähän on kuitenkin tietokannan rekonstruointi tiedostoista, eikö niin?)

Kun uskot, että sinulla on tiedot paikassa, joka on valmis palautettavaksi mihin tahansa sovellukseen, jossa tiedot ovat kadonneet, tiedot ovat vioittuneet tai niissä on vain virheellisiä tietoja, on aika valmistautua ottamaan tiedot paikalliselta koneeltasi ja lähettämään ne takaisin lähde.

Takaisin Lähteeseen

Ensinnäkin kaikki edellä mainitut on suositeltavaa tehdä vähäliikenteen aikoina, joten varmista, että aina kun teet tämän, et tee sitä ruuhka-aikoina. Tämän pitäisi olla sanomattakin selvää.

Ota seuraavaksi varmuuskopio tietokannasta ennen kuin alat käyttää sitä. Tallenna tiedosto sellaiseen paikkaan, jonka voit helposti muistaa ja johon pääset helposti käsiksi. Jos jokin menee pieleen tuotavien tietojen käytössä, olet suojattu ja palautat vain sen, mitä olet tuomassa. Selvyyden vuoksi vie koko tietokanta SQL-muodossa.

Ota nyt tietokanta, joka sinulla on paikallisella koneellasi, ja vie tiedot myös SQL-tiedostoon. Avaa viety tiedosto ja varmista, että se käyttää CREATE – käskyä tietokannan luomiseen oikealla nimellä ja taulukot myös oikeanimillä.

Olettaen, että kaikki menee hyvin, kaikki tuomasi palautetaan täsmälleen sellaisena kuin sen pitäisi olla ja kuten näet paikallisella laitteellasi. Jos et näe sitä, tuo aiemmin viemäsi tiedosto. muuten olet hyvä lähtemään.

Entä jos se ei toimi?

Jos se ei auta, sinun on mentävä perusongelmaan:

Eikö se toiminut, koska palvelimen tiedostoissa oli jotain vikaa?
Eikö se toiminut paikallisella koneellasi luomasi tietokannan tyypin vuoksi?
Käytätkö samaa tallennusmoottoria? Sinun pitäisi olla, koska se tulee tiedostoista.
Onko tietokannan eheys kiinteä paikallisesti?
Poistetaanko palvelimen tietokanta ennen tietojen tuontia paikalliselta koneeltasi?

Jos se ei toimi tässä vaiheessa, se johtuu yleensä jostain yllä olevasta. Se voi kuitenkin olla jotain muuta. Olen tehnyt kaikkeni tarjotakseni mahdollisimman paljon tietoa MySQL-tietokannoista, niiden rakenteesta ja tarvittavista vaiheista tietokannan rekonstruoimiseksi tiedostoista, mutta en pysty kaappaamaan kaikkia mahdollisia reunatapauksia.

Varmuuskopioi tiedot aina (äläkä oleta, että se on tehty)

Toivon kuitenkin, että kaikki yllä olevat tiedot antavat syvemmän käsityksen siitä, mitä WordPressin alla piilee, jos kohtaat tämän ongelman yksin tai asiakkaan kanssa.

Ja lopuksi aina varmuuskopio. Tee manuaaliset varmuuskopiot, tee automaattiset varmuuskopiot ja tee ne usein. Älä myöskään rajoita sitä tietokantaan. Varmuuskopioi tietokanta, sovellus ja kaikki muu ratkaisun tehostamiseen tarvittava.

Jos teet niin, sinun ei tarvitse huolehtia kaikesta edellä mainitusta.

: tommcfarlin.com