Ist das Sichern einer MySQL-Datenbank in Git eine gute Idee?

Ich versuche, die Sicherungssituation für meine Anwendung zu verbessern. Ich habe eine Django-Anwendung und eine MySQL-Datenbank. Ich habe einen Artikel gelesen, in dem vorgeschlagen wird, die Datenbank in Git zu sichern.

Einerseits gefällt es mir, da es eine Kopie der Daten und des Codes synchron hält.

Git ist jedoch für Code konzipiert, nicht für Daten. Als solches wird es eine Menge zusätzlicher Arbeit tun, die den MySQL-Speicherauszug bei jedem Commit unterscheidet, was nicht wirklich notwendig ist. Wenn ich die Datei vor dem Speichern komprimiere, unterscheidet git die Dateien trotzdem?

(Die Dump-Datei ist derzeit 100 MB unkomprimiert, 5,7 MB, wenn es um Informationen geht.)

Bearbeiten: Die Code- und Datenbankschemadefinitionen befinden sich bereits in Git. Es handelt sich tatsächlich um die Daten, die ich jetzt sichern möchte.

Bevor Sie Daten verlieren, möchte ich versuchen, diese Frage aus der Perspektive eines Systemadministrators zu betrachten.

Es gibt nur einen Grund, warum wir Backups erstellen: Es ist möglich, Backups wiederherzustellen, wenn etwas schief geht, wie es ausnahmslos der Fall ist. Als solches hat ein richtiges Backup-System Anforderungen , die weit über das hinausgehen, was Git vernünftigerweise handhaben kann.

Hier sind einige der Probleme, die ich beim Versuch, Ihre Datenbank in git zu sichern, vorhersehen kann:

• Das Repository wird mit jedem "Backup" dramatisch wachsen. Da git ganze Objekte speichert (wenn auch komprimiert) und sie später ändert (z. B. wenn Sie ausführen git gc) und den Verlauf für immer beibehält , werden sehr viele Daten gespeichert, die Sie nicht wirklich benötigen oder sogar wollen. Möglicherweise müssen Sie die Menge oder den Aufbewahrungszeitraum von Backups einschränken, um Speicherplatz zu sparen, oder aus rechtlichen Gründen. Es ist jedoch schwierig , alte Revisionen aus einem Git-Repo zu entfernen, ohne dass dabei viel Kollateralschaden entsteht.
• Die Wiederherstellung ist auf Zeitpunkte beschränkt, die Sie im Repository gespeichert haben, und da die Daten so groß sind, kann es langsam sein, mehr als eine unbedeutende Zeitspanne zurückzulegen. Ein speziell für diesen Zweck entwickeltes Backup-System begrenzt die Menge der gespeicherten Daten, bietet jedoch möglicherweise mehr Granularität und ermöglicht schnellere Wiederherstellungen, wodurch Ausfallzeiten im Katastrophenfall verringert werden. Datenbank-fähige Backup-Lösungen ( Beispiel ) können auch kontinuierliche Backups bereitstellen , um sicherzustellen, dass keine einzige Transaktion verloren geht.
• Commits sind wahrscheinlich ebenfalls langsam und werden langsamer, wenn die Datenbank wächst. Denken Sie daran, dass git im Wesentlichen ein Schlüsselwertdatenspeicher ist, der einem Dateisystem zugeordnet ist und daher den Leistungsmerkmalen des zugrunde liegenden Dateisystems unterliegt. Es ist möglich, dass dieser Zeitraum das Sicherungsintervall überschreitet und Sie Ihr SLA zu diesem Zeitpunkt nicht mehr einhalten können. Richtige Sicherungssysteme benötigen mit zunehmender Datenmenge auch mehr Zeit für die Sicherung, sind jedoch bei weitem nicht so umfangreich, da sie automatisch ihre eigene Größe basierend auf der von Ihnen konfigurierten Aufbewahrungsrichtlinie verwalten.

Trotz der Tatsache, dass es anscheinend einige interessante Dinge gibt, die Sie mit einem Datenbank-Dump tun können, wenn Sie ihn in git einfügen, kann ich ihn insgesamt nicht empfehlen, um Backups zu erstellen. Vor allem, da Backup-Systeme weit verbreitet sind (und viele sogar Open Source- Systeme sind ) und die Sicherheit Ihrer Daten erheblich verbessern und eine schnellstmögliche Wiederherstellung ermöglichen.

Meine zwei Cent: Ich halte es nicht für eine gute Idee. GIT tut so etwas wie „Speichern von Snapshots eines Satzes von Dateien an verschiedenen Punkten in der Zeit“, so dass Sie kann perfekt GIT verwenden für so etwas, aber das bedeutet nicht , Sie sollten . GIT wurde entwickelt, um Quellcode zu speichern, so dass Ihnen die meisten Funktionen fehlen und Sie viel Leistung für ein wenig Bequemlichkeit eintauschen würden.

Lassen Sie mich annehmen, dass der Hauptgrund, warum Sie darüber nachdenken, darin besteht, "eine Kopie der Daten und des Codes synchron zu halten". Dies bedeutet, dass Sie befürchten, dass Version 2.0 Ihres Codes ein anderes Datenbankschema als Version 1.0 benötigt . Eine einfachere Lösung wäre, das Datenbankschema als eine Reihe von SQL-Skripten mit CREATEAnweisungen zusammen mit dem Quellcode in Ihrem Git-Repository zu speichern . Ein Teil Ihrer Installationsprozedur besteht dann darin, diese Skripte auf einem zuvor installierten Datenbankserver auszuführen.

Der tatsächliche Inhalt dieser CREATETabellen hat nichts mit der Version Ihres Quellcodes zu tun. Stellen Sie sich vor, Sie installieren Ihre Software, Version 1.0, auf Server A und Server B, die in verschiedenen Unternehmen von verschiedenen Teams verwendet werden. Nach einigen Wochen wird der Inhalt der Tabellen sehr unterschiedlich sein, obwohl die Schemata genau gleich sind.

Da Sie den Inhalt der Datenbank sichern möchten, empfehle ich Ihnen, ein Sicherungsskript zu verwenden, das den Sicherungsspeicherauszug mit der aktuellen Version der Software kennzeichnet, zu der der Speicherauszug gehört. Das Skript sollte sich im GIT-Repository befinden (damit es Zugriff auf die Quellcode-Versionszeichenfolge hat), die Speicherauszüge selbst gehören jedoch nicht zu einem Versionskontrollsystem.

EDIT :

Nachdem ich den ursprünglichen Beitrag gelesen habe, der die Frage motiviert hat , finde ich dies eine noch zweifelhaftere Idee. Der entscheidende Punkt ist, dass der mysqldumpBefehl den aktuellen Status einer Datenbank in eine Reihe von SQL- INSERTAnweisungen umwandelt und GIT diese unterscheiden kann, um nur die aktualisierten Tabellenzeilen abzurufen.

Der mysqldumpTeil ist solide, da dies eine der Sicherungsmethoden ist, die in der MySQL-Dokumentation aufgeführt sind. Im GIT-Teil merkt der Autor nicht, dass Datenbankserver ein Transaktionsprotokoll führen , um Abstürze, einschließlich MySQL , zu beheben . Es wird mit diesem Protokoll , nicht GIT, dass Sie inkrementelle Backups für Ihre Datenbank erstellen soll. Dies hat in erster Linie den Vorteil, dass Sie die Protokolle nach der Wiederherstellung rotieren oder leeren können, anstatt ein GIT-Repository bis ins Unendliche und darüber hinaus aufzublähen ...

Persönlich halte ich es nicht für eine gute Idee, ein Versionsverwaltungssystem zum Speichern der Sicherungsdateien zu verwenden, da die GIT-Versionsverwaltung für Datendateien und nicht für Binärdateien oder Sicherungsdateien wie eine MySQL-Sicherungssicherungsdatei konzipiert ist. Die Tatsache, dass Sie dies tun können, bedeutet nicht automatisch, dass Sie es tun sollten . Darüber hinaus wird Ihr Repository unter Berücksichtigung einer neuen Datenbanksicherung für jedes neue Commit dramatisch anwachsen, wobei viel Festplattenspeicher belegt wird und die Leistung von GIT beeinträchtigt wird, was zu einem langsamen Quellcodeverwaltungssystem führt. Für mich ist es in Ordnung, eine Sicherungsstrategie auszuführen und immer eine Sicherungsdatei parat zu haben, wenn Sie die Datenbank wiederherstellen müssen, wenn etwas in Ihrem Code schief geht, aber die Tools zur Versionskontrolle sind nicht dafür gemacht, Binärdaten zu speichern.

Aus diesen Gründen wird kein Dienstprogramm zum Speichern der Sicherungsdateien für Tag 1 und Tag 2 sowie zum Anzeigen der Unterschiede zwischen den beiden Sicherungsdateien angezeigt. Es wird viel zusätzliche und nutzlose Arbeit erfordern. Anstatt GIT zum Speichern von Datenbanksicherungen zu verwenden, wenn Sie neuen Code festschreiben, speichern Sie die Datenbanksicherungen in einem anderen Pfad, getrennt nach Datum und Uhrzeit, und fügen Sie in Ihren Code einen Verweis auf die neuen Datenbanksicherungen ein, die für jede Version mithilfe der Tags erstellt wurden. wie schon jemand vorgeschlagen hat.

Mein letzter Hinweis zu den Datenbank-Backups und GIT: Wenn ein Datenbankadministrator eine Datenbank wiederherstellen muss, weil einige Daten verloren gegangen sind, muss er nicht die Unterschiede zwischen der Sicherungsdatei für Tag 1 und der Sicherungsdatei für Tag 2 überprüfen, sondern nur wissen, welche Letzte Sicherungsdatei, mit der er die Datenbank ohne Fehler und Datenverlust wiederherstellen und Ausfallzeiten reduzieren kann. In der Tat besteht die Aufgabe eines Datenbankadministrators darin, die Daten so schnell wie möglich für die Wiederherstellung verfügbar zu machen, wenn das System aus bestimmten Gründen ausfällt. Wenn Sie die mit Ihren Commits verknüpften Datenbanksicherungen in GIT speichern, kann der Datenbankadministrator die Daten nicht schnell wiederherstellen, da Ihre Sicherungen auf die Zeitpunkte beschränkt sind, die Sie im GIT-Repository gespeichert haben, und um die Ausfallzeit zu verringern vom System,

Ich empfehle dann nicht, die Sicherungen mit GIT zu speichern, sondern eine gute Sicherungssoftwarelösung zu verwenden (es gibt einige davon hier ), die mehr Granularität bietet und es Ihnen ermöglicht, Ihre Daten sicher zu verwahren und zu sichern Datenrettung im Katastrophenfall einfach und schnell.

Sie sollten keine Binärdaten in Git speichern - insbesondere nicht in der Datenbank.
Codeänderungen und Datenbank-DML-Änderungen sind völlig verschiedene Dinge.

MySQL und Oracle können Archivprotokolle schreiben, um sie zu jedem Zeitpunkt wiederherzustellen. Sichern Sie einfach diese Protokolle an einem sicheren Ort und Sie werden in Ordnung sein.

Die Verwendung von Git zum Sichern dieser "Archivprotokolle" ist nicht sinnvoll. Archivprotokolle in Produktionsumgebungen sind ziemlich umfangreich und sollten nach regelmäßigen vollständigen Sicherungen entfernt werden. Es ist auch sinnlos, sie in git zu setzen - diese sind in gewisser Weise bereits ein Aufbewahrungsort.