Forse spingerai un codice che finisce per rompere una cache che fornisce dati a milioni di persone,
Forse aggiornerai un’applicazione e finirai per spazzare via le informazioni di cui non è stato eseguito il backup,
O forse spingerai una modifica che "funziona sulla tua macchina" ma riempie completamente il repository di controllo del codice sorgente.

E ci sono molti altri esempi. Sono sicuro che puoi nominarne rapidamente altri cinque tu stesso.

Ho impegnato (gioco di parole, una specie di) la mia giusta quota di tutto quanto sopra, ma una delle cose che vedo dalle persone che lavorano nel nostro spazio.

Cioè, coloro che lavorano con applicazioni Web supportate da database, è la mancanza di comprensione dell’organizzazione del database a livello di file system e di come sia possibile ricostruire i dati anche quando non si dispone di un backup standard su cui lavorare.

In questo post, approfondirò l’organizzazione del database MySQL a livello di file system, come ripristinare le informazioni da quello rispetto a un file di backup se dovessi trovarti in quella situazione e fornire riferimenti (o segnalibri) dovrebbero ne hai bisogno.

Ricostruzione dati MySQL

Per essere chiari, parlerò di un database MySQL in esecuzione su una variante di un sistema operativo basato su *nix (quindi stai guardando una distribuzione di Linux o macOS).

Le posizioni dei file (che tratterò momentaneamente) varieranno su un sistema basato su Windows, ma dovrai fare riferimento al manuale MySQL o a una risorsa simile per trovarli.

Il punto è: prima di approfondire questo articolo, scopri dove risiedono i file sul tuo sistema operativo. Ad esempio, se stai utilizzando macOS e probabilmente lo troverai in /usr/local/mysql/data.

Preferisco usare Homebrew quindi i miei database MySQL sono in /usr/local/var/mysql . E come puoi vedere sopra, noterai file che hanno lo stesso nome dei database che hai sul tuo sistema .

Come sono organizzati i database

A livello di superficie, sembra piuttosto semplice. Ma se devi aprire la directory come menzionato sopra, scoprirai che gran parte di ciò che vedi sono directory – non file, di per sé – che contengono più informazioni.

Se approfondisci una delle directory, vedrai una varietà di file:

Questi includono file che includono i seguenti tipi:

MONDO
MIO
FR
IBD

E ognuno di questi tipi di file esiste per ogni tabella nel database.

Quindi diamo un’occhiata a questi più in profondità per avere una maggiore comprensione di cosa sia esattamente costituito da un database.

1 Il database è un insieme di file

In generale, la maggior parte di noi sa che MySQL è un database relazionale e ogni database è costituito da un insieme di tabelle che memorizzano tutti diversi tipi di informazioni (e molte tabelle sono correlate tra loro in qualche modo anche se è solo un valore in un singola colonna).

Ma questo post non riguarda l’aspetto relazionale del database né il modo in cui siamo in grado di eseguire query su di esso. (Se sei interessato, fallo: è tutto basato sul calcolo delle tuple .)

Si tratta invece di comprendere che per ogni tabella esiste un insieme di file che fanno riferimento alle informazioni contenute in ogni tabella. E

2 Comprendere i tipi di file

Poiché ogni tabella in un database è composta dai tipi di file precedenti, esaminiamo il singolo tipo di file e quindi determiniamo il ruolo che svolge per ciascuna tabella (e, in definitiva, come ciò influisce sull’intero database).

MIO. Questo file contiene i dati archiviati nelle righe della tabella del database. Questo file è strettamente correlato al file FRM.
FR. Questo file contiene i dati in formato tabella (che includono cose come la struttura di ciascuna colonna del database, il tipo di dati che contiene e così via).
MIO. Questo è l’indice del database. Se stai usando un database MyISAM (che la maggior parte di noi sta usando InnoDB a questo punto), avrai questo file. Inoltre, i dati includono informazioni sul fatto che i dati siano stati chiusi correttamente o meno. Considera questo un file sull’integrità della tabella stessa. Non le informazioni al suo interno, non il formato di esso.
IBD. Questo è un tipo di file associato alle tabelle del database InnoDB (quindi potresti non vederlo nella directory del tuo database). Se lo fai, tuttavia, è importante sapere che i database basati su InnoDB memorizzeranno le informazioni su ciascuna tabella in questo file.

Nelle informazioni di cui sopra, ci sono altri due argomenti che vale la pena esplorare.

Il mio ISAM
InnoDB

Prima di esaminare ciascuno di questi, nota che MyISAM e InnoDB sono quelli che vengono definiti motori di archiviazione. Sembra stravagante, ma ha a che fare con il modo in cui il software del database gestisce le operazioni di creazione, lettura, aggiornamento ed eliminazione delle informazioni.

MyISAM e InnoDB: qual è la differenza?

Ciascuno di questi motori di archiviazione differisce nel modo in cui gestiscono transazioni, blocco, rollback e ricerche. Per coloro che sono amministratori di database, hai familiarità con tutto quanto sopra (ma probabilmente non lo stai leggendo 🙃).

Non questo tipo di motore, ovviamente.

Per il resto di noi, questo è quello che abbiamo:

Le transazioni si verificano ogni volta che almeno due istruzioni come SELECT e UPDATE o INSERT e DELETE o qualsiasi combinazione delle due (o più) vengono utilizzate insieme l’una all’altra. Quindi, se dovessi SELEZIONARE le informazioni e quindi CANCELLARE i risultati, avresti una transazione.
- MyISAM non supporta le transazioni. Ciò significa che se una "transazione" viene interrotta, tutti i dati che sono stati elaborati durante l’operazione sono interessati. Inutile dire che questo non viene utilizzato.
- InnoDB, invece, garantisce che le modifiche non verranno apportate alla tabella fino al completamento della transazione. In altre parole, le modifiche non verranno salvate nel database.
Per ciascuno dei motori di archiviazione, il blocco varia a livello di tabella o di riga. Ogni volta che esegui una query su una tabella, MyISAM bloccherà l’intera tabella fino al completamento del processo. InnoDB, dall’altro, bloccherà solo le righe interessate. Questa è una distinzione importante perché significa che puoi continuare a operare su una tabella, ma non sulle stesse righe, ogni volta che utilizzi InnoDB.
I rollback non sono possibili in MyISAM. Ciò significa che una volta apportata una modifica, è fatta. InnoDB offre rollback. Quindi supponiamo che tu apporti una modifica al tavolo, hai accidentalmente fatto qualcosa che non volevi fare, quindi puoi riportarlo allo stato precedente. Questo non deve essere confuso con un backup, però. È più simile a un’operazione di "annullamento" per una transazione.
La ricerca, soprattutto nel modo in cui strutturiamo i nostri database, è fondamentale nel modo in cui organizziamo i dati nei nostri database. In poche parole, InnoDB supporta l’indicizzazione FULLTEXT (a partire da MySQL 5.6.4). Ma se il tuo host o provider non consente gli indici FULLTEXT, direi che non è un rompicapo.

Date tutte le informazioni di cui sopra, ognuno vede che i vantaggi del motore di archiviazione InnoDB superano di gran lunga quelli del motore di archiviazione MyISAM, specialmente se sei sopra per utilizzare una versione di MySQL almeno uguale a 5.6.4

3 Ricreare il database

A questo punto, supponiamo che tu sappia di avere accesso ai file che compongono il database dal sistema operativo.

Forse è un backup precedente, forse sei in grado di individuare i file su disco, o forse sei in grado di recuperarli in qualche altro modo e devi ripristinare il database a un punto precedente.

1 Non farlo in produzione

Prima di fare qualsiasi cosa, imposta un database vuoto sul tuo computer locale e poi lavora per importare le informazioni. Ma, ancora una volta, non è come usare semplicemente un front-end di database per importare un file SQL.

Creare invece una directory che corrisponda al nome del database che si desidera creare. In questo post, userò l’esempio di trunkdev (poiché è qui che lavoro utilizzando la versione più recente di WordPress trunk ).

2 Eseguire il backup del database esistente

Successivamente, eseguire il backup del database esistente il più possibile, utilizzando un front-end del database o una copia dei file. Successivamente, copia i file dal percorso di origine nella directory che hai creato.

Dovresti, a questo punto, essere in grado di caricare il front-end del tuo database preferito e vedere le informazioni contenute nei file di database che hai appena copiato. Ciò dipende dal fatto che i file non siano danneggiati e che il server di database sia in esecuzione.

3 Non installare altro software

Nota che, a questo punto, non proverei a installare altri software su di esso come WordPress o altre informazioni. Invece, lavora direttamente con i dati. Supponendo che sia visibile nel tuo front-end, esegui un backup o un’esportazione adeguati del file in un file SQL in modo da poter ripristinare più facilmente le informazioni in futuro.

Alcuni front-end ti daranno la possibilità di esportare solo determinate tabelle. In questo caso, eseguire il backup di tutto. Per alcuni database, ciò richiederà molto tempo; per gli altri, non tanto. Tutto dipende dalle dimensioni del progetto.

4 Lavora con i dati

A questo punto, dovresti essere in grado di iniziare a manipolare il database utilizzando il front-end o SQL. Se non ti senti a tuo agio o non sei nemmeno sicuro di come farlo, parla con qualcuno che lo è perché può essere qualcosa di incredibilmente sensibile (dopotutto, hai a che fare con la ricostruzione di un database da file, giusto?)

Una volta che ritieni di avere le informazioni in un luogo pronto per essere ripristinato in qualsiasi applicazione abbia perso informazioni, informazioni danneggiate o semplicemente abbia dati non validi, allora è il momento di prepararti a prendere le informazioni dal tuo computer locale e rispedirle al fonte.

Torna alla fonte

Innanzitutto, si consiglia di eseguire tutto quanto sopra durante i periodi di traffico ridotto, quindi assicurati che ogni volta che lo fai, non lo farai durante le ore di lavoro di punta. Questo dovrebbe essere ovvio.

Quindi, esegui un backup del database prima di iniziare a utilizzarlo. Salva il file in una posizione che puoi facilmente richiamare e accedere facilmente in modo che se qualcosa va storto nell’utilizzo delle informazioni che stai per importare, sei coperto e ripristina semplicemente ciò che era già lì. Per essere chiari, esporta l’intero database in formato SQL.

Ora prendi il database che hai sul tuo computer locale ed esporta anche quelle informazioni in un file SQL. Aprire il file esportato e assicurarsi che stia utilizzando un’istruzione CREATE per creare il database con il nome proprio e anche le tabelle con i nomi propri.

Supponendo che tutto vada bene, tutto ciò che hai importato verrà ripristinato esattamente come dovrebbe essere e come vedi sul tuo dispositivo locale. Se non lo vedi, importa il file che hai esportato in precedenza; altrimenti sei a posto.

E se non funziona?

Se non funziona, dovrai arrivare al problema principale:

Non ha funzionato a causa di qualcosa di sbagliato con i file dal server?
Non ha funzionato a causa del tipo di database che hai creato sul tuo computer locale?
Stai usando lo stesso motore di archiviazione? Dovresti esserlo dato che proviene dai file.
L’integrità del database è solida a livello locale?
Il database sul server viene eliminato prima di importare i dati dal tuo computer locale?

Se a questo punto non funziona, di solito è a causa di qualcosa di simile a quello che c’è sopra. Tuttavia, potrebbe essere qualcos’altro. Ho fatto il possibile per fornire quante più informazioni possibili sui database MySQL, su come sono strutturati e sui passaggi necessari per ricostruire il database dai file, ma non riesco a catturare ogni potenziale caso limite.

Effettua sempre il backup dei dati (e non dare per scontato che sia stato fatto)

Detto questo, spero che tutte le informazioni di cui sopra forniscano una comprensione più profonda di ciò che si nasconde sotto WordPress se dovessi affrontare questo problema da solo o con un cliente.

E, infine, sempre il backup. Esegui backup manuali, esegui backup automatici e falli frequentemente. Non limitarlo nemmeno al database. Eseguire il backup del database, dell’applicazione e di quant’altro necessario per alimentare la soluzione.

Se lo fai, non dovrai preoccuparti di tutto quanto sopra.

Fonte di registrazione: tommcfarlin.com