Re: OT? MySQL Backup auf WIN ?

[Martin Ramsch <m.ramsch_(at)_computer.org>]

Cyrill Schumacher schrieb am Donnerstag, den  2. September 1999,
in der deutschen PHP-Mailingliste:
> Wenn der mysqld läuft und neue Datenbanken angelegt werden mit Daten
> drin, dann wird das ja nicht sofort auf die Festplatte geschrieben,
> sondern es ist alles im Rechner RAM, aber was ist wenn der Rechner
> abstürzt oder ein Heini den mysqld durch Strg+Alt+Entf einfach so
> beendet.  Die Daten sind dann weg !? Oder wie ?

Ja, leider.  Aber das ist halt das grundsätzliche Problem mit Puffern.

Entweder keine Puffer und alles wird immer sofort auf die Festplatte
geschrieben: dann geht auch bei Stromausfall nichts verloren, aber es
ist halt langsam.
Oder mit schnellen Puffern, aber dann kann ein harter Abbruch zu
Datenverlusten führen.

> Schreibt mysqld erst beim runterfahren durch mysqladmin die Daten
> auf die Festplatte ?

Nein, die Daten werden _meisten_ sogar unmittelbar auf die Festplatte
in die Tabellendateien gespeichert, aber die exakten Umstände, wann
etwas länger im Speicher bleibt, weiß ich leider auch nicht.  Als
Daumenregel kannst Du Dir aber merken, daß Daten im Speicher gepuffert
sein _können_.

Deshalb gibt's auch extra die SQL-Anweisung "FLUSH TABLES", die dafür
sorgt, daß alle Änderungen auf die Platte geschrieben werden.

> Falls das alles so ist, ist es witzlos jede Nacht einen Backup über
> das Verzeichnis, wo die Datenbanken drin liegen, laufen zu
> lassen....

Zumindest fehlerträchtig ist es.  Insbesondere wenn zur Zeit des
Backups auch noch Änderungen in der Datenbank stattfinden, ist es gut
möglich, daß die *.ISM, *.ISD, *.frm-Dateien in MySQLs
Datenverzeichnis _nicht_ den aktuellen Zusatend der Tabellen
widerspiegeln.  Wenn nichts los ist, dann hat MySQL die letzten
Änderungen schon längst geschrieben und das Backup ist okay.

Für ein "perfektes" Backup sollte man deshalb

a) entweder den MySQL-Server herunterfahren und dann erst
   Sicherheitskopien der Tabellendateien machen,

b) Oder: zum Sichern der Tabelle "kunden" läßt man ein Skript laufen
   (z.B. in Perl), das der Reihe nach diese Befehle ausführt:

     LOCK TABLES kunden READ;
       /* damit nicht andere Threads Datenänderungen machen können,
          während wir kopieren. */

     FLUSH TABLES;
       /* damit MySQL den aktuellen Zustand der Tabelle auch sicher
          in die Tabellen-Dateien geschrieben hat. */

     /*
     Jetzt im Perl-Skript die Dateien "junden.ISM", "kunden.ISD"
     und "kunde.frm" kopieren.
     */

     UNLOCK TABLES;
       /* Tabelle wieder zum allgemeinen Zugrioff freigeben. */

c) Alternativ kannst Du auch einfach einen kompletten Dump einer
   MySQL-Datenbank erzeugen mit:
     mysqldump --opt dbname >dbname.dump

   Da so ein Dump SQL-Anweisungen enthält, mit denen man die Datenbank
   neu erzeugen könnte, ist er etwas größer als die reinen Tabellen-
   dateien.  Aber er läßt sich gut mit gzip o.ä. komprimieren und hat
   zudem den Vorteil, daß man die Daten im Katastrophenfall in lesbarer
   Form hat, die man (evtl. mit kleinen Anpassungen) sogar mit anderen
   SQL-DBMS verwenden kann.

Ciao,
  Martin
-- 
Martin Ramsch <m.ramsch_(at)_computer.org> <URL: http://ramsch.home.pages.de/ >
PGP: 0xE8EF4F75, 52 44 5E F3 B0 B1 38 26  E4 EC 80 58 7B 31 3A D7

---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe