it-swarm.com.de

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 geben, die den MySQL-Dump bei jedem Commit unterscheidet, was nicht wirklich notwendig ist. Wenn ich die Datei vor dem Speichern komprimiere, unterscheidet git die Dateien dann noch?

(Die Dump-Datei ist derzeit 100 MB unkomprimiert, 5,7 MB beim Bzippen.)

Bearbeiten: Die Code- und Datenbankschema-Definitionen sind bereits in Git enthalten. Es sind wirklich die Daten, die ich jetzt sichern möchte.

58
wobbily_col

Bevor Sie Daten verlieren, möchte ich versuchen, dieser Frage eine Sysadmin-Perspektive zu geben.

Es gibt nur einen Grund, warum wir Backups erstellen: um die Wiederherstellung zu ermöglichen, wenn etwas schief geht, wie es immer der Fall ist. Als solches ein richtiges Backup-System hat 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 speichert ganze Objekte (wenn auch komprimiert) und dann nterscheidet sie später (z. B. wenn Sie git gc Ausführen) und behält den Verlauf Für immer wird eine sehr große Datenmenge gespeichert, die Sie nicht wirklich benötigen oder gar wollen. Möglicherweise müssen Sie die Anzahl oder Aufbewahrungsdauer von Sicherungen, die Sie durchführen, um Speicherplatz zu sparen, oder aus rechtlichen Gründen begrenzen, aber es ist schwierig, zu entfernen alte revisionen von einem git repo ohne viel kollateralschaden.
  • Das Wiederherstellen ist auf Zeitpunkte beschränkt, die Sie im Repository gespeichert haben. Da die Daten so groß sind, kann das Zurückgehen von mehr als einer unbedeutenden Zeitspanne langsam sein. Ein speziell für diesen Zweck entwickeltes Sicherungssystem begrenzt die gespeicherte Datenmenge und bietet möglicherweise mehr Granularität sowie schnellere Wiederherstellungen, wodurch Ausfallzeiten im Katastrophenfall reduziert werden. Datenbankbewusste Sicherungslösungen ( Beispiel ) können auch kontinuierliche Sicherungen bereitstellen, um sicherzustellen, dass keine einzige Transaktion verloren geht.
  • Commits sind wahrscheinlich auch langsam und werden langsamer, wenn die Datenbank wächst. Denken Sie daran, dass git im Wesentlichen ein Schlüsselwert-Datenspeicher, der einem Dateisystem zugeordnet ist ist und daher den Leistungsmerkmalen des zugrunde liegenden Dateisystems unterliegt. Es ist möglich, dass diese Zeitspanne das Sicherungsintervall überschreitet, und zu diesem Zeitpunkt können Sie Ihre SLA nicht mehr einhalten. Die Sicherung ordnungsgemäßer Sicherungssysteme dauert auch länger, wenn die Daten wachsen, jedoch nicht annähernd so dramatisch, da sie automatisch ihre eigene Größe basierend auf der von Ihnen konfigurierten Aufbewahrungsrichtlinie verwalten.

Trotz der Tatsache, dass es anscheinend mehrere interessante Dinge gibt, die Sie mit einem Datenbank-Dump machen können, wenn Sie ihn in git einfügen, kann ich ihn insgesamt nicht empfehlen, um Backups zu erstellen. Zumal Backup-Systeme sind weit verbreitet (und viele sind sogar Open Source) und arbeiten viel besser daran, Ihre Daten sicher zu halten und eine möglichst schnelle Wiederherstellung zu ermöglichen.

101
Michael Hampton

Meine zwei Cent: Ich halte das nicht für eine gute Idee. GIT macht so etwas wie "Speichern von Schnappschüssen einer Reihe von Dateien zu verschiedenen Zeitpunkten", also verwenden Sie können GIT perfekt für so etwas, aber das bedeutet nicht, dass Sie sollte. GIT wurde zum Speichern von Quellcode entwickelt, sodass Ihnen der größte Teil seiner Funktionalität fehlt und Sie viel Leistung gegen ein wenig Komfort 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", und 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 CREATE -Anweisungen entlang des Quellcodes in Ihrem Git-Repository zu speichern. Ein Teil Ihrer Installationsprozedur besteht dann darin, diese Skripts auf einem zuvor installierten Datenbankserver auszuführen.

Der tatsächliche Inhalt dieser nur CREATE- d-Tabellen 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 von verschiedenen Teams in verschiedenen Unternehmen 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, würde ich Ihnen empfehlen, ein Sicherungsskript zu verwenden, das Tags den Sicherungsspeicherauszug mit der aktuellen Version der Software enthält, zu der der Speicherauszug gehört. Das Skript sollte sich im GIT-Repository befinden (damit es Zugriff auf die Versionszeichenfolge des Quellcodes hat), aber die Speicherauszüge selbst gehören nicht zu einem Versionskontrollsystem.

[~ # ~] edit [~ # ~] :

Nach dem Lesen des rsprünglicher Beitrag, der die Frage motiviert hat finde ich dies eine noch zweifelhaftere Idee. Der entscheidende Punkt ist, dass der Befehl mysqldump den aktuellen Status einer Datenbank in eine Reihe von SQL-Anweisungen INSERT umwandelt und GIT sie unterscheiden kann, um nur die aktualisierten Tabellenzeilen abzurufen.

Der Teil mysqldump ist solide, da dies eine der Sicherungsmethoden ist, die in der MySQL-Dokumentation aufgeführt sind. Im GIT-Teil bemerkt der Autor nicht, dass Datenbankserver ein Transaktionsprotokoll führen, um sich von Abstürzen zu erholen, einschließlich MySQL . Es ist nter Verwendung dieses Protokolls , nicht GIT, dass Sie inkrementelle Sicherungen für Ihre Datenbank erstellen sollten. Dies hat in erster Linie den Vorteil, dass Sie die Protokolle nach der Wiederherstellung drehen oder leeren können, anstatt ein GIT-Repository ins Unendliche und darüber hinaus aufzublähen ...

39
logc

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

Aus diesen Gründen sehe ich kein Dienstprogramm beim Speichern der Sicherungsdateien für Tag 1 und für Tag 2 und dann beim Erkennen der Unterschiede zwischen den beiden Sicherungsdateien. 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 jemand schon vorgeschlagen hat.

Mein letzter Hinweis zu den Datenbanksicherungen und zum GIT : Ein Datenbankadministrator benötigt keine Datenbank, wenn er eine Datenbank wiederherstellen muss, weil einige Daten verloren gegangen sind Um die Unterschiede zwischen der Sicherungsdatei für Tag 1 und der Sicherungsdatei für Tag 2 zu überprüfen, muss er nur wissen, welche Sicherungsdatei die letzte ist, mit der er die Datenbank ohne Fehler und Datenverlust wiederherstellen kann, wodurch Ausfallzeiten reduziert werden. 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 Datenbanksicherungen in GIT speichern, die mit Ihren Commits verknüpft sind, erlauben Sie dem Datenbankadministrator nicht, die Daten schnell wiederherzustellen, da Ihre Sicherungen auf Zeitpunkte beschränkt sind, die Sie im GIT-Repository gespeichert haben, und um die Ausfallzeit zu verringern des Systems, da die Leistung Ihres GIT-Repositorys drastisch reduziert wird, da viele Daten gespeichert werden müssen.

Dann empfehle ich nicht, die Backups mit GIT zu speichern, sondern eine gute Backup-Softwarelösung zu verwenden (es gibt einige davon hier ), die mehr Granularität bietet und es Ihnen ermöglicht, Ihre Daten zu behalten sicher und sicher und macht Ihre Datenwiederherstellung im Katastrophenfall einfach und schnell.

7
Alberto Solano

Sie sollten keine Binärdaten in Git speichern - insbesondere keine 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 diese Protokolle einfach 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 stecken - diese sind in gewissem Sinne bereits ein Repository.