Ho accidentalmente lasciato cadere tutti i tavoli. Posso ripristinare? Non ho la copia di backup.
Ho accidentalmente lasciato cadere tutti i tavoli. Posso ripristinare? Non ho la copia di backup.
Risposte:
Se non hai letteralmente alcun backup, sono sicuro al 99% che sei sfortunato.
Se hai qualche forma di backup, per quanto vecchia, allora hai attivato la registrazione binaria tramite l'opzione log-bin nel file di configurazione di MySQL (my.ini)? In tal caso potrebbero essere in grado di recuperare dall'ultimo backup.
Brutto modo di iniziare una settimana amico, scusa.
La domanda è piuttosto vecchia, ma non esiste una sola risposta positiva, quindi ne aggiungerò una.
Dopo che MySQL ha eliminato una tabella, i dati sono ancora sul supporto per un po '. Quindi puoi recuperare i record e ricostruire una tabella. Più avanti ne parlerò sul blog, ma per ora uno schizzo veloce.
Dovresti avere una struttura della tabella (istruzione CREATE TABLE).
Se innodb_file_per_table è ON, la tabella rilasciata si trova sulla partizione del disco. Arresta MySQL e reinstallalo il prima possibile in sola lettura. Se MySQL si trovava su una partizione di root (che non è una buona idea tra l'altro), quindi prendere un'immagine o estrarre il disco e collegarlo a un altro server. Ferma tutte le scritture in altre parole.
Se innodb_file_per_table OFF, basta semplicemente arrestare MySQL.
Quindi scaricare e compilare lo strumento di rilascio per InnoDB da https://github.com/twindb/undrop-for-innodb/ . Controlla il post " Compilazione del toolkit di recupero TwinDB " per i dettagli.
Quindi analizzare la partizione del disco o ibdata1 (a seconda dell'impostazione innodb_file_per_table) con stream_parser:
./stream_parser -f /path/to/diskimage_or_ibdata1
Quindi recuperare il dizionario InnoDB per sapere in quale indice_id era la tabella eliminata.
Quindi prendere la struttura della tabella e recuperare i record
./c_parser -f pages-diskimage_or_ibdata1/FIL_PAGE_INDEX/00000<index_id>.page
Trasmetterà i record su stdout e il comando LOAD DATA su stderr.
Ecco cosa ho fatto. Nella directory mysql (per Ubuntu questo è / var / lib / mysql, per Mac usando Homebrew questo è / usr / local / var / mysql), ho trovato alcuni file. Per prima cosa ho copiato la directory myapp_development / contenente lo schema particolare nella mia directory mysql locale. Quindi ho eseguito il backup del mio ibdata1 locale e copiato ibdata1 del server nella directory mysql. Mysqld ucciso. ( ps auxper trovare il PID, quindi kill PID). Riavviato mysql, è stato avviato in modalità di ripristino di emergenza. Quindi ha avviato il mio client mysql locale e generato un dump completo delle tabelle di cui avevo bisogno.
E, 15.000 file che rappresentano settimane di lavoro che entrano nei metadati che pensavamo fossero andati per sempre, vengono salvati !!
Spero che questo aiuti qualcuno.
Sfortunatamente c'è molto poco che puoi fare, oltre a portare via una lezione molto preziosa sulla necessità di un buon piano di backup.
A seconda del tipo di tabella potresti essere in grado di trovare un esperto in grado di riunire i dati da ciò che ha lasciato sul disco, ma tale analisi forense sarebbe molto molto molto costosa (in quanto richiederebbe competenze relativamente non comuni) e non è affatto garantita per essere veramente utile.
Se questa era la tabella MyISAM, devi solo ripristinare i file della tabella in / var / log / mysql o qualunque sia la tua directory dei dati. Ad esempio, è possibile utilizzare l' utilità ext3grep .
Non puoi "annullare" a DROP TABLE.
Puoi vedere e vedere se MySQL aveva la registrazione binaria abilitata, forse puoi estrarre alcuni dati da lì.
Oltre a questo, puoi dimenticare MySQL e avere la stessa classe di problemi di "Ho cancellato accidentalmente alcuni file dal mio filesystem". Ci sono alcuni strumenti là fuori che provano a recuperare file, e ci sono anche aziende che lo fanno su base professionale.
Se la registrazione binaria è attivata, è possibile ricreare prima una tabella se si dispone di uno schema. Assicurati di creare uno schema mentre i binlog sono disattivati. Oppure puoi semplicemente saltare la sessione. Quindi è possibile riprodurre i binlog fino all'ultima istruzione che era la tabella di rilascio stessa.
In caso contrario, è possibile ripristinare utilizzando un dump di backup, se presente. Se si dispone di file CSV, è possibile eseguire il metodo di caricamento dei dati per recuperare i dati. Se si sta eseguendo il ripristino da mysqldump, è possibile prendere in considerazione il ripristino di una singola tabella dal file di dump anziché il ripristino del database completo. Se la dimensione dei dati è troppo grande, è possibile prendere in considerazione la disabilitazione delle chiavi prima di caricarla, aumentando in modo significativo il processo di ripristino.
Per il futuro potresti voler avere uno schiavo ritardato con un ritardo di circa 10-24 ore. Puoi creare uno slave ritardato usando percona toolkit (pt-slave-delay)