Kanske kommer du att trycka kod som slutar med att en cache som serverar data till miljontals människor,
Kanske kommer du att uppdatera en applikation och sluta med att du blåser bort information som inte är säkerhetskopierad,
Eller så kanske du trycker på en ändring som "fungerar på din maskin" men som fullständigt spolar källkontrollförrådet.

Och det finns många andra exempel. Jag är säker på att du snabbt kan namnge fem till själv.

Jag har åtagit mig (typ av ordlek) min beskärda del av allt ovan men en av de saker som jag ser från människor som arbetar i vårt utrymme.

Det vill säga de som arbetar med databasstödda webbapplikationer – är bristen på förståelse för databasorganisation på filsystemsnivå och hur det är möjligt att rekonstruera data även när man inte har en standard backup att fungera av.

I det här inlägget ska jag ta en djupdykning i MySQL-databasorganisationen på filsystemnivå, hur du kan återställa information från den kontra en säkerhetskopia om du skulle hamna i den situationen, och ge referenser (eller bokmärken) bör du behöver dem.

MySQL-datarekonstruktion

För att vara tydlig, kommer jag att prata om en MySQL-databas som körs på en variant av ett *nix-baserat operativsystem (så du tittar på en distribution av Linux eller macOS).

Platserna för filerna (som jag kommer att täcka tillfälligt) kommer att variera på ett Windows-baserat system, men du måste hänvisa till MySQL-manualen eller en liknande resurs för att hitta dem.

Poängen är: Innan du går för långt in i den här artikeln, vet var filerna finns i ditt operativsystem. Till exempel, om du kör macOS och då kommer du sannolikt att hitta det i /usr/local/mysql/data.

Jag föredrar att använda Homebrew så mina MySQL-databaser finns i /usr/local/var/mysql . Och som du kan se ovan kommer du att märka filer som har samma namn som databaserna som du har på ditt system .

Hur databaser är organiserade

På ytnivå ser det ganska enkelt ut. Men om du ska öppna katalogen som nämnts ovan, kommer du att upptäcka att mycket av det du ser är kataloger – inte filer i sig – som innehåller mer information.

Om du borrar ner i en av katalogerna kommer du att se en mängd olika filer:

Dessa inkluderar filer som inkluderar följande typer:

VÄRLD
MYI
FRM
IBD

Och var och en av dessa typer av filer finns för varje tabell i databasen.

Så låt oss titta på dessa mer djupgående för att få en större förståelse för exakt vad en databas består.

1 Databasen är en uppsättning filer

Generellt sett vet de flesta av oss att MySQL är en relationsdatabas och varje databas består av en uppsättning tabeller som alla lagrar olika typer av information (och många tabeller är relaterade till varandra på något sätt även om det bara är ett värde i en enkel kolumn).

Men det här inlägget handlar inte om den relationella aspekten av databasen och inte heller om hur vi kan köra frågor mot den. (Om du är intresserad, ha det – allt är baserat på tupelkalkyl .)

Istället handlar det om att förstå att det för varje tabell finns en uppsättning filer som refererar till information i varje tabell. Och

2 Förstå filtyperna

Eftersom varje tabell i en databas består av ovanstående filtyper, låt oss titta på den individuella filtypen och sedan bestämma vilken roll den spelar för varje tabell (och i slutändan hur detta påverkar hela databasen).

MYD. Den här filen innehåller data som är lagrade i raderna i databastabellen. Denna fil är nära relaterad till FRM-filen.
FRM. Den här filen innehåller data i tabellformatet (som inkluderar saker som hur varje kolumn i databasen är tänkt att vara strukturerad, vilken typ av data den innehåller och så vidare).
MYI. Detta är databasindexet. Om du använder en MyISAM-databas (som de flesta av oss använder InnoDB vid det här laget), kommer du att ha den här filen. Vidare innehåller uppgifterna information om huruvida uppgifterna har stängts ordentligt eller inte. Betrakta detta som en fil om själva tabellens integritet. Inte informationen i den, inte formatet på den.
IBD. Detta är en filtyp som är associerad med InnoDB-databastabeller (så du kanske inte ser detta i din databas katalog). Om du gör det är det dock viktigt att veta att InnoDB-baserade databaser kommer att lagra information om varje tabell i den här filen.

I ovanstående information finns det två andra ämnen värda att utforska.

MyISAM
InnoDB

Innan du tittar på var och en av dessa, notera att MyISAM och InnoDB är vad som kallas lagringsmotorer. Det låter fancy, men det har att göra med hur databasprogramvaran hanterar operationerna för att skapa, läsa, uppdatera och ta bort information.

MyISAM & InnoDB: Vad är skillnaden?

Var och en av dessa lagringsmotorer skiljer sig åt i hur de hanterar transaktioner, låsning, återställningar och sökningar. För de som är databasadministratörer, du är bekant med allt ovan (men du läser troligen inte det här 🙃).

Inte den här typen av motor, förstås.

För resten av oss har vi det här:

Transaktioner sker när minst två uttalanden som SELECT och UPDATE eller INSERT och DELETE eller någon kombination av de två (eller flera) används tillsammans med varandra. Så om du skulle VÄLJA information och sedan RADERA resultaten, skulle du ha en transaktion.
- MyISAM stöder inte transaktioner. Detta innebär att om en "transaktion" avbryts så påverkas all data som bearbetades under operationen. Behöver säga att detta inte används.
- InnoDB, å andra sidan, garanterar att ändringarna inte kommer att göras i tabellen förrän transaktionen är genomförd. Med andra ord kommer ändringarna inte att bindas till databasen.
För var och en av lagringsmotorerna varierar låsningen på tabellnivå eller radnivå. Närhelst du kör en fråga mot en tabell, kommer MyISAM att låsa hela tabellen tills processen är klar. InnoDB, å andra sidan, kommer bara att låsa de rader som påverkas. Detta är en viktig skillnad eftersom det betyder att du kan fortsätta att arbeta på en tabell, bara inte samma rader, när du använder InnoDB.
Återställning är inte möjlig i MyISAM. Det betyder att när en förändring väl är gjord så är den gjord. InnoDB erbjuder återställningar. Så låt oss säga att du gör en förändring av tabellen, du av misstag gjorde något du inte menade att göra, sedan kan du rulla tillbaka det till dess tidigare tillstånd. Detta ska dock inte förväxlas med en säkerhetskopia. Det är mer som en "ångra"-operation för en transaktion.
Sökning, särskilt i hur vi strukturerar våra databaser, är nyckeln i hur vi organiserar data i våra databaser. Enkelt uttryckt stöder InnoDB FULLTEXT- indexering (från och med MySQL 5.6.4). Men om din värd eller leverantör inte tillåter FULLTEXT-index, skulle jag hävda att det inte är en dealbreaker.

Med tanke på all information ovan, är det var och en att se att fördelarna med InnoDB-lagringsmotorn vida överväger fördelarna med MyISAM-lagringsmotorn, särskilt om du är ovan för att använda en version av MySQL som är minst lika med 5.6.4

3 Återskapa databasen

Låt oss nu anta att du vet att du har tillgång till filerna som utgör databasen från operativsystemet.

Kanske är det en tidigare säkerhetskopia, kanske kan du hitta filerna på disken, eller kanske kan du hämta dem på något annat sätt – och du behöver återställa databasen till en tidigare punkt.

1 Gör det inte i produktion

Innan du gör något, skapa en tom databas på din lokala dator och arbeta sedan med att importera informationen. Men återigen, det här är inte som att bara använda ett databasgränssnitt för att importera en SQL-fil.

Skapa istället en katalog som matchar namnet på databasen som du vill skapa. I det här inlägget kommer jag att använda exemplet trunkdev (eftersom det är här jag jobbar med den senaste versionen från WordPress trunk ).

2 Säkerhetskopiera den befintliga databasen

Säkerhetskopiera sedan den befintliga databasen så mycket som möjligt – oavsett om det är med ett databasgränssnitt eller en kopia av filerna. Efter det kopierar du filerna från källplatsen till katalogen som du skapade.

Du bör vid det här laget kunna ladda upp ditt valbara databasgränssnitt och se informationen som finns i databasfilerna som du just kopierade. Detta är beroende av att filerna inte är skadade och att databasservern körs.

3 Installera inte annan programvara

Observera att jag vid det här laget inte skulle försöka installera annan programvara på den som WordPress eller annan information. Arbeta istället direkt med datan. Förutsatt att den är synlig i din front-end, gör en ordentlig säkerhetskopiering eller export av filen till en SQL-fil så att du lättare kan återställa informationen i framtiden.

Vissa gränssnitt ger dig möjligheten att endast exportera vissa tabeller. I det här fallet, säkerhetskopiera allt. För vissa databaser kommer detta att ta lång tid; för andra, inte så mycket. Allt beror på projektets storlek.

4 Arbeta med data

Vid det här laget bör du kunna börja manipulera databasen med front-end eller SQL. Om du inte är bekväm eller ens säker på hur du gör detta, prata med någon som är det eftersom detta kan vara något som är otroligt känsligt (trots allt, du har att göra med att rekonstruera en databas från filer, eller hur?)

När du tror att du har informationen på en plats som är redo att återställas till vilken applikation som helst förlorad information, skadad information eller helt enkelt har felaktig data, då är det dags att förbereda dig för att ta informationen från din lokala dator och skicka tillbaka den till källa.

Tillbaka till källan

För det första rekommenderas allt ovanstående att göras under tider med låg trafik, så se till att när du gör detta kommer du inte att göra det under högtrafik. Detta borde vara självklart.

Ta sedan en säkerhetskopia av databasen innan du börjar använda den. Spara filen på en plats som du enkelt kan återkalla och lätt komma åt så att om något går fel med att använda informationen du ska importera, då är du täckt och återställer helt enkelt det som redan fanns där. För att vara tydlig, exportera hela databasen i SQL-format.

Ta nu databasen som du har på din lokala dator och exportera den informationen till en SQL-fil också. Öppna den exporterade filen och se till att den använder en CREATE – sats för att skapa databasen med rätt namn och tabellerna med rätt namn också.

Förutsatt att allt går bra kommer allt du har importerat att återställas exakt som det ska vara och som du ser på din lokala enhet. Om du inte ser det, importera sedan filen du exporterade tidigare; annars är du bra att gå.

Vad händer om det inte fungerar?

Om det inte fungerar, måste du gå ner till rotproblemet:

Fungerade det inte på grund av något fel med filerna från servern?
Fungerade det inte på grund av den typ av databas du skapade på din lokala dator?
Använder du samma lagringsmotor? Du borde vara det eftersom det kommer från filerna.
Är databasens integritet stabil lokalt?
Raderas databasen på servern innan data importeras från din lokala dator?

Om det inte fungerar vid det här laget, kommer det vanligtvis att bero på något liknande det som är ovan. Det kan dock vara något annat. Jag har gjort vad jag kan för att tillhandahålla så mycket information som möjligt om MySQL-databaser, hur de är uppbyggda och de steg som krävs för att rekonstruera databasen från filer, men jag kan inte fånga alla potentiella kantfall.

Säkerhetskopiera alltid data (och anta inte att det görs)

Som sagt, jag hoppas att all information ovan ger en djupare förståelse för vad som ligger under WordPress om du skulle möta detta problem på egen hand eller med en kund.

Och slutligen alltid backup. Gör manuella säkerhetskopior, gör automatiska säkerhetskopior och gör dem ofta. Begränsa det inte till databasen heller. Säkerhetskopiera databasen, applikationen och allt annat som behövs för att driva lösningen.

Om du gör det behöver du inte oroa dig för allt ovan.

Inspelningskälla: tommcfarlin.com