Knud: wie sichert Ihr die MySQL-Datenbanken?

Hallo,

auf meinem Server läuft mittlerweile eine kleine Shop-Geschichte über die auch tatsächlich 24 Stunden bestellt wird.
Jetz würd ich gern die Datenbanken archivieren, natürlich unter Vermeidung möglicher Inkonsistenten durch geöffneter Tabellen.
Muss ich (wie zur Zeit) mir einen Zeitpunkt ausdenken, an dem MySQL zunächst mal stoppe, dann die Sicherung fahre und danach MySQL wieder starte und damit den Benutzer für eine Weile mit einer Fehlermeldung vertrösten muss?

Gruß,

Knud

  1. Hi,

    ist ganz einfach (Jedenfalls unter Windows). Jede Datenbank die MySQL anlegt entspricht einem Verzeichnis. d.h. Die Datenbank "ABC" ist im Mysql/data/ABC verzeichnis. Innerhalb dieses Verzeichnisses hat jede Tabelle drei Dateien Test.frm, test.myd und test.myi.

    Dieses Verzeichnis kopierst du dir einfach weg.

    gruss

    Ralf

    1. Hi!

      Tja, händisch funktioniert es auch soweit, zumindest ohne Fehlermeldung.
      Anders als bei entsprechenden Programmen, die automatisiert diese Dateien kopieren sollen. Diese melden nämlich "Dateien geöffnet..." und kopieren nicht.
      Und dabei haben sie nicht ganz unrecht. Denn man stelle sich vor, dass einzelne Tabellen doch schon recht umfangreich und groß sein können. So im Rahmen mehrerer MB. Je größer diese Dateien sind desto einleuchtender wirds eigentlich. Wenn mämlich nun diese Dateien kopiert werden sollen,
      fängt er mit der tabelle1.* an und danach mit tabelle2.* etc.
      Aber während des Kopierens kann doch schon wieder der Inhalt der Tabellen verändert worden sein. Und das kann böse Folgen haben --> Inkonsistenz!
      So können in einer Tabelle Daten angelegt worden sein, die sich auf Daten aus einer anderen Tabelle beziehen, die ebenso gerade eben erst angelegt worden sind. Und noch schlimmer, das kann ja auch schon bei der Tabelle selber passieren, bestehen doch die Tabellen-Informationen aus 3 Dateien (frm,myd,myi).
      Im Grunde kann dieses Problem bei jeder noch so kleinen Tabelle auftreten, wenn auch deutlich unwarscheinlicher.
      Nimm einfach mal an, die Dateien wären so groß, dass an einer einzigen Datei, mehrere Stunden kopiert wird, dann sieht jeder, das führt zu einem Problem.

      Und genau für dieses Problem würd ich gern wissen, wie es andere gelöst haben. Fahren sie wirklich die Datenbank erst runter oder gibts da doch andere Möglichkeiten?

      Gruß,

      Knud

      1. Hi Knud,

        Aber während des Kopierens kann doch schon wieder
        der Inhalt der Tabellen verändert worden sein.
        Und das kann böse Folgen haben --> Inkonsistenz!

        fein - Du hast selbst gemerkt, daß Dein Problem Transaktionssicherheit erfordert. Schließlich ist es ja auch ein Transaktionssystem, das Du da betreibst.

        Welche Tabellentypen verwendest Du denn?
        Irgendwas von den höherwertigen (InnoBD, BDB), oder ganz einfaches myISAM und dann "gut würfeln"?

        Und genau für dieses Problem würd ich gern wissen,
        wie es andere gelöst haben. Fahren sie wirklich die
        Datenbank erst runter oder gibts da doch andere
        Möglichkeiten?

        Im ersteren Falle würde Dir der transaktionssichere Treiber erlauben, eine eigene Datenbankanwendung zu starten, welche eine konsistente Sicht auf die Tabelle besitzt. Du würdest über diese Transaktion sämtliche Tabellen in einem Rutsch auslesen und irgendwohin sichern können. Alle währenddessen vorgenommenen Änderungen würde die Datenbank außerhalb des Sichtbereichs Deiner Anwendung durchführen.

        Eine professionelle Datenbank (Oracle und Konsorten) würde übrigens fertige Tools für eine solche Online-Sicherung mitliefern.
        Der Knackpunkt ist aber die Transaktionsfähigkeit (den Rest kannst Du Dir leicht selber schreiben).

        Deshalb hättest Du mit myISAM und Ähnlichem m. E. leider verloren.
        Da es um finanziell relevante Daten geht, würde ich die harte Methode (housekeeping-Phase mit entsprechender Meldung) gegenüber inkonsistenten Daten (und entsprechendem Seriositätsverlust oder gar justistischen Folgeerscheinungen) vorziehen.

        Viele Grüße
              Michael