Vielleicht pushen Sie Code, der am Ende einen Cache sprengt, der Millionen von Menschen Daten liefert,
Vielleicht aktualisieren Sie eine Anwendung und verlieren am Ende Informationen, die nicht gesichert sind,
Oder vielleicht pushen Sie eine Änderung, die „auf Ihrem Rechner funktioniert“, aber das Quellcodeverwaltungs-Repository vollständig überfordert.

Und es gibt noch viele weitere Beispiele. Ich bin sicher, Sie können selbst schnell fünf weitere nennen.

Ich habe (Wortspiel beabsichtigt, irgendwie) meinen fairen Anteil an all dem oben Genannten begangen, aber eines der Dinge, die ich von Leuten sehe, die in unserem Bereich arbeiten.

Das heißt, diejenigen, die mit datenbankgestützten Webanwendungen arbeiten – ist das mangelnde Verständnis der Datenbankorganisation auf Dateisystemebene und wie es möglich ist, Daten zu rekonstruieren, selbst wenn Sie kein Standard-Backup haben, mit dem Sie arbeiten können.

In diesem Beitrag werde ich einen tiefen Einblick in die MySQL-Datenbankorganisation auf Dateisystemebene nehmen, wie Sie Informationen aus dieser im Vergleich zu einer Sicherungsdatei wiederherstellen können, falls Sie sich in dieser Situation befinden, und Referenzen (oder Lesezeichen) bereitstellen sollten du brauchst sie.

MySQL-Datenrekonstruktion

Um es klar zu sagen, ich werde über eine MySQL-Datenbank sprechen, die auf einer Variante eines * nix-basierten Betriebssystems läuft (Sie sehen sich also eine Linux- oder MacOS-Distribution an).

Die Speicherorte der Dateien (die ich gleich behandeln werde) variieren auf einem Windows-basierten System, aber Sie müssen im MySQL-Handbuch oder einer ähnlichen Ressource nachschlagen, um sie zu finden.

Der Punkt ist: Bevor Sie zu weit in diesen Artikel gehen, sollten Sie wissen, wo sich die Dateien auf Ihrem Betriebssystem befinden. Wenn Sie beispielsweise macOS ausführen, finden Sie es wahrscheinlich in /usr/local/mysql/data.

Ich ziehe es vor, Homebrew zu verwenden, daher befinden sich meine MySQL-Datenbanken in /usr/local/var/mysql . Und wie Sie oben sehen können, werden Sie Dateien bemerken, die denselben Namen haben wie die Datenbanken, die Sie auf Ihrem System haben .

Wie Datenbanken organisiert sind

An der Oberfläche sieht es ziemlich einfach aus. Aber wenn Sie das Verzeichnis wie oben erwähnt öffnen, werden Sie feststellen, dass vieles, was Sie sehen, Verzeichnisse sind – nicht Dateien an sich – die mehr Informationen enthalten.

Wenn Sie in eines der Verzeichnisse gehen, sehen Sie eine Vielzahl von Dateien:

Dazu gehören Dateien der folgenden Typen:

WELT
MEIN ICH
FRM
IBD

Und jeder dieser Dateitypen existiert für jede Tabelle in der Datenbank.

Schauen wir uns diese also genauer an, um ein besseres Verständnis dafür zu bekommen, woraus eine Datenbank besteht.

1 Die Datenbank ist eine Reihe von Dateien

Im Allgemeinen wissen die meisten von uns, dass MySQL eine relationale Datenbank ist und jede Datenbank aus einer Reihe von Tabellen besteht, die alle verschiedene Arten von Informationen speichern (und viele Tabellen sind auf irgendeine Weise miteinander verbunden, selbst wenn es sich nur um einen Wert in a einzelne Spalte).

In diesem Beitrag geht es jedoch weder um den relationalen Aspekt der Datenbank noch darum, wie wir Abfragen darauf ausführen können. (Wenn Sie interessiert sind, haben Sie es – es basiert alles auf Tupelkalkül .)

Stattdessen geht es darum zu verstehen, dass es für jede Tabelle eine Reihe von Dateien gibt, die auf die in jeder Tabelle enthaltenen Informationen verweisen. Und

2 Die Dateitypen verstehen

Da jede Tabelle in einer Datenbank aus den oben genannten Dateitypen besteht, schauen wir uns den einzelnen Dateityp an und bestimmen dann die Rolle, die er für jede Tabelle spielt (und wie sich dies letztendlich auf die gesamte Datenbank auswirkt).

MYD. Diese Datei enthält die Daten, die in den Zeilen der Datenbanktabelle gespeichert sind. Diese Datei ist eng mit der FRM-Datei verwandt.
FRM. Diese Datei enthält die Tabellenformatdaten (die Dinge enthalten, wie z. B. wie jede Spalte der Datenbank strukturiert werden soll, die Art der Daten, die sie enthält, und so weiter).
MYI. Dies ist der Datenbankindex. Wenn Sie eine MyISAM-Datenbank verwenden (die meisten von uns verwenden derzeit InnoDB), werden Sie diese Datei haben. Ferner umfassen die Daten Informationen darüber, ob die Daten ordnungsgemäß geschlossen wurden oder nicht. Betrachten Sie dies als eine Datei über die Integrität der Tabelle selbst. Nicht die Informationen darin, nicht das Format davon.
IBD. Dies ist ein Dateityp, der mit InnoDB-Datenbanktabellen verknüpft ist (so dass Sie dies möglicherweise nicht im Verzeichnis Ihrer Datenbank sehen). In diesem Fall ist es jedoch wichtig zu wissen, dass InnoDB-basierte Datenbanken Informationen zu jeder Tabelle in dieser Datei speichern.

In den obigen Informationen gibt es zwei weitere Themen, die es wert sind, untersucht zu werden.

MyISAM
InnoDB

Bevor Sie sich diese ansehen, beachten Sie, dass MyISAM und InnoDB sogenannte Speicher-Engines sind. Es klingt ausgefallen, aber es hat damit zu tun, wie die Datenbanksoftware die Vorgänge zum Erstellen, Lesen, Aktualisieren und Löschen von Informationen verwaltet .

MyISAM & InnoDB: Was ist der Unterschied?

Jede dieser Speicher-Engines unterscheidet sich darin, wie sie mit Transaktionen, Sperren, Rollbacks und Suchen umgehen. Diejenigen, die Datenbankadministratoren sind, sind mit all dem oben Genannten vertraut (aber Sie lesen dies wahrscheinlich auch nicht 🙃).

Natürlich nicht diese Art von Motor.

Für den Rest von uns haben wir Folgendes:

Transaktionen treten immer dann auf, wenn mindestens zwei Anweisungen wie SELECT und UPDATE oder INSERT und DELETE oder eine beliebige Kombination der beiden (oder mehr) in Verbindung miteinander verwendet werden. Wenn Sie also Informationen AUSWÄHLEN und dann die Ergebnisse LÖSCHEN würden, hätten Sie eine Transaktion.
- MyISAM unterstützt keine Transaktionen. Das bedeutet, wenn eine „Transaktion“ unterbrochen wird, sind alle Daten betroffen, die während der Operation verarbeitet wurden. Es muss gesagt werden, dass dies nicht verwendet wird.
- InnoDB hingegen garantiert, dass die Änderungen erst nach Abschluss der Transaktion an der Tabelle vorgenommen werden. Mit anderen Worten, die Änderungen werden nicht in die Datenbank übernommen.
Für jede der Speicher-Engines variiert das Sperren auf Tabellen- oder Zeilenebene. Immer wenn Sie eine Abfrage für eine Tabelle ausführen, sperrt MyISAM die gesamte Tabelle, bis der Vorgang abgeschlossen ist. InnoDB hingegen sperrt nur die betroffenen Zeilen. Dies ist ein wichtiger Unterschied, denn es bedeutet, dass Sie weiterhin mit einer Tabelle arbeiten können, nur nicht mit denselben Zeilen, wenn Sie InnoDB verwenden.
Rollbacks sind in MyISAM nicht möglich. Dies bedeutet, dass eine einmal vorgenommene Änderung abgeschlossen ist. InnoDB bietet Rollbacks an. Nehmen wir also an, Sie nehmen eine Änderung an der Tabelle vor, Sie haben versehentlich etwas getan, was Sie nicht tun wollten, dann können Sie sie auf ihren vorherigen Zustand zurücksetzen. Dies ist jedoch nicht mit einem Backup zu verwechseln. Es ist eher wie ein „Rückgängig“-Vorgang für eine Transaktion.
Die Suche, insbesondere die Art und Weise, wie wir unsere Datenbanken strukturieren, ist der Schlüssel dazu, wie wir Daten in unseren Datenbanken organisieren. Einfach ausgedrückt unterstützt InnoDB die FULLTEXT- Indizierung (ab MySQL 5.6.4). Aber wenn Ihr Host oder Anbieter keine FULLTEXT-Indizes zulässt, würde ich argumentieren, dass dies kein Dealbreaker ist.

Angesichts all der oben genannten Informationen ist es jedem klar, dass die Vorteile der InnoDB-Speicher-Engine die der MyISAM-Speicher-Engine bei weitem überwiegen, insbesondere wenn Sie darüber nachdenken, eine Version von MySQL zu verwenden, die mindestens 5.6.4 entspricht

3 Datenbank neu erstellen

Nehmen wir an dieser Stelle an, dass Sie wissen, dass Sie vom Betriebssystem aus Zugriff auf die Dateien haben, aus denen die Datenbank besteht.

Vielleicht ist es eine frühere Sicherung, vielleicht können Sie die Dateien auf der Festplatte finden oder sie auf andere Weise abrufen – und Sie müssen die Datenbank zu einem früheren Zeitpunkt wiederherstellen.

1 Tun Sie es nicht in der Produktion

Bevor Sie irgendetwas tun, richten Sie eine leere Datenbank auf Ihrem lokalen Computer ein und arbeiten Sie dann daran, die Informationen zu importieren. Aber auch dies ist nicht so, als würde man einfach ein Datenbank-Front-End verwenden, um eine SQL-Datei zu importieren.

Erstellen Sie stattdessen ein Verzeichnis, das mit dem Namen der Datenbank übereinstimmt, die Sie erstellen möchten. In diesem Beitrag verwende ich das Beispiel von trunkdev (da ich hier mit der neuesten Version von WordPress trunk arbeite ).

2 Sichern Sie die vorhandene Datenbank

Als nächstes sichern Sie die vorhandene Datenbank so weit wie möglich – sei es mit einem Datenbank-Frontend oder einer Kopie der Dateien. Kopieren Sie danach die Dateien vom Quellspeicherort in das von Ihnen erstellte Verzeichnis.

An diesem Punkt sollten Sie in der Lage sein, das Datenbank-Frontend Ihrer Wahl zu laden und die Informationen anzuzeigen, die in den gerade kopierten Datenbankdateien enthalten sind. Dies ist abhängig davon, dass die Dateien nicht beschädigt sind und der Datenbankserver läuft.

3 Installieren Sie keine andere Software

Beachten Sie, dass ich an dieser Stelle nicht versuchen würde, andere Software wie WordPress oder andere Informationen darauf zu installieren. Arbeiten Sie stattdessen direkt mit den Daten. Unter der Annahme, dass es in Ihrem Front-End sichtbar ist, führen Sie eine ordnungsgemäße Sicherung durch oder exportieren Sie die Datei in eine SQL-Datei, damit Sie die Informationen in Zukunft einfacher wiederherstellen können.

Einige Frontends geben Ihnen die Möglichkeit, nur bestimmte Tabellen zu exportieren. Sichern Sie in diesem Fall alles. Bei manchen Datenbanken dauert dies sehr lange; für andere nicht so sehr. Es hängt alles von der Größe des Projekts ab.

4 Arbeiten Sie mit den Daten

An diesem Punkt sollten Sie in der Lage sein, die Datenbank mit dem Front-End oder SQL zu manipulieren. Wenn Sie sich nicht wohl fühlen oder sich nicht sicher sind, wie das geht, dann sprechen Sie mit jemandem, der es ist, da dies etwas sein kann, das unglaublich sensibel ist (schließlich haben Sie es mit der Rekonstruktion einer Datenbank aus Dateien zu tun, oder?)

Sobald Sie glauben, dass Sie die Informationen an einem Ort haben, der bereit ist, für jede Anwendung wiederhergestellt zu werden, verlorene Informationen, beschädigte Informationen oder einfach fehlerhafte Daten, dann ist es an der Zeit, sich darauf vorzubereiten, die Informationen von Ihrem lokalen Computer zu nehmen und an den zurückzusenden Quelle.

Zurück zur Quelle

Erstens wird empfohlen, alle oben genannten Schritte während Zeiten mit geringem Datenverkehr durchzuführen. Stellen Sie also sicher, dass Sie dies immer dann tun, wenn Sie dies nicht während der Hauptarbeitszeiten tun. Dies sollte selbstverständlich sein.

Erstellen Sie als Nächstes eine Sicherungskopie der Datenbank, bevor Sie mit der Arbeit beginnen. Speichern Sie die Datei an einem Ort, an den Sie sich leicht erinnern und auf den Sie leicht zugreifen können, damit Sie abgesichert sind und einfach wiederherstellen können, was bereits vorhanden war, falls bei der Verwendung der zu importierenden Informationen etwas schief geht. Exportieren Sie zur Verdeutlichung die gesamte Datenbank im SQL-Format.

Nehmen Sie nun die Datenbank, die Sie auf Ihrem lokalen Computer haben, und exportieren Sie diese Informationen auch in eine SQL-Datei. Öffnen Sie die exportierte Datei und stellen Sie sicher, dass sie eine CREATE – Anweisung verwendet, um die Datenbank mit dem richtigen Namen und auch die Tabellen mit den richtigen Namen zu erstellen.

Unter der Annahme, dass alles gut geht, wird alles, was Sie importiert haben, genau so wiederhergestellt, wie es sein sollte und wie Sie es auf Ihrem lokalen Gerät sehen. Wenn Sie das nicht sehen, importieren Sie die zuvor exportierte Datei. ansonsten sind Sie gut zu gehen.

Was ist, wenn es nicht funktioniert?

Wenn es nicht funktioniert, müssen Sie sich dem Grundproblem widmen:

Hat es nicht funktioniert, weil etwas mit den Dateien vom Server nicht stimmt?
Hat es aufgrund des Datenbanktyps, den Sie auf Ihrem lokalen Computer erstellt haben, nicht funktioniert?
Verwenden Sie dieselbe Speicher-Engine? Sie sollten es sein, da es aus den Dateien stammt.
Ist die Integrität der Datenbank lokal stabil?
Wird die Datenbank auf dem Server gelöscht, bevor die Daten von Ihrem lokalen Computer importiert werden?

Wenn es zu diesem Zeitpunkt nicht funktioniert, liegt es normalerweise an etwas wie dem, was oben steht. Es könnte jedoch auch etwas anderes sein. Ich habe mein Möglichstes getan, um so viele Informationen wie möglich über MySQL-Datenbanken bereitzustellen, wie sie strukturiert sind und welche Schritte erforderlich sind, um die Datenbank aus Dateien zu rekonstruieren, aber ich kann nicht jeden potenziellen Grenzfall erfassen.

Immer Daten sichern (und nicht davon ausgehen, dass es fertig ist)

Ich hoffe jedoch, dass alle oben genannten Informationen ein tieferes Verständnis dafür vermitteln, was WordPress zugrunde liegt, falls Sie dieses Problem alleine oder mit einem Kunden haben.

Und schließlich immer Backup. Führen Sie manuelle Sicherungen durch, führen Sie automatische Sicherungen durch und tun Sie dies regelmäßig. Beschränken Sie es auch nicht auf die Datenbank. Sichern Sie die Datenbank, die Anwendung und alles andere, was zum Betrieb der Lösung erforderlich ist.

Wenn Sie dies tun, müssen Sie sich um all die oben genannten Dinge keine Sorgen machen.

Aufnahmequelle: tommcfarlin.com