Backup von Datenbanken

[Marco Schumann]

Hi,

> > außerdem habe ich immer noch nicht die Sicherheit,
>  > dass die Daten dann schon auf der Festplatte sind.
> du hast die Sicherheit, das der Server keine Daten mehr
> im RAM hat, die eigentlich auf die Platte sollten
>
> und was das Betriebssystem puffert, interessiert dich
> nicht, da es da beim kopieren selbst drauf achtet

interessant, hatte ich gar nicht bedacht

>
> > mysqldump macht sich aber gut :-)
> wenn du ein in sich konsistentes Backup haben möchtest,
> solltest du darauf achten, das du -l für "read lock all
> tables" benutzt, sonst können Schreibvorgänge während
> des Dumps sowohl Tabellen ändern, die du bereits gedumpt
> hast als auch solche, die noch gedumpt werden müssen

OUTFILE='/name/of/file'
mysqldump -uusername -ppassword --databases \
  --add-drop-table --lock-tables --complete-insert \
  --extended-insert --all --flush db1 db2 ... > $OUTFILE

sollte ein READ LOCK setzen

> ok, der Server ist damit noch erreichbar, erlaubt aber
> während des Dumps nur Lesezugriffe, und ein Dump dauert
> i.A. einiges länger als ein shutdown-copy-startup, das
> Einspielen des Dumps dauert sogar *wesentlich* länger,
> da alle Indices neu erzeugt werden müssen (auch wenn
> das in 4.0.1 mit DISABLE/ENABLE KEYS einiges flotter
> geworden ist)

ich hoffe, es kommt nicht zum Einspielen, und wenn doch, dann habe ich
(leider) Zeit :-)

> bleibt noch die Alternative mit BACKUP/RESTORE TABLE,
> hier mußt du in Sachen Konsistenz zwar dafür sorgen,
> das du für voneinander abhängige Tabellen selbst
> Read-Locks anforderst, aber ansonsten hast du die
> Vorteile des Kopierens mit der durchgängigen Erreichbarkeit
> des Servers kombiniert ...

ist zu überdenken

Vielen Dank

Marco

---
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql