mySql: Fragen zu Cache und Dumps

[steckl]

Hi,

ich muss in 2 Wochen die Abschlusspraesentation meiner Lehre als Fachinformatiker /Anwendungsentwicklung halten. Hier muss ich mein Projekt (Webinterface zum wiedereinspielen von Dumps in eine mySql-DB) vor einem Pruefungsausschuss vorstellen.

Hier wuerde ich gerne zwei Aussagen bringen, bei denen ich mir aber nicht 100-prozentig sicher bin, ob sie richtig sind:

a) Backups von einer mySql-DB sind nicht nur noetig, weil die Platte kaputt gehen kann, sondern auch, weil mySql viele Daten im Cache haelt, die, wenn der Server abstuerzt, nicht mehr auf die Festplatte geschrieben werden koennen. Die Daten im Cache koennen auch mehrere Tage alt sein.

b) Der Vorteil eines Backups in Form von Dumps, anstatt die DB-Files direkt zu kopieren, ist es erstens, dass man nicht erst den Cache leeren muss und zweitens dass Dumps leichter kompatibel mit anderen mySql-Versionen sind.

Da ich bei dem Vortrag nicht durch Falschaussagen unnoetig inkompetent wirken will waere es gut, wenn jemand, der davon mehr Ahnung hat, diese beiden Aussagen kurz bewerten koennte.

mfG,
steckl

[wahsaga]

hi,

b) Der Vorteil eines Backups in Form von Dumps, anstatt die DB-Files direkt zu kopieren, ist es erstens, dass man nicht erst den Cache leeren muss und zweitens dass Dumps leichter kompatibel mit anderen mySql-Versionen sind.

Ein Nachteil wäre dann, dass man einen Dump erst wieder "einspielen" muss, was u.U. ziemlich zeitaufwendig sein kann - wohingegen "Dateien kopieren" bei angehaltenem Server fix gehen dürfte.

Aber "Dateien kopieren" ist eine Variante, bei der es eigentlich jeden Admin schaudern lassen sollte.
Die Wahrscheinlichkeit, etwas "kaputt zu machen"; ggf. nicht mehr zueinander passende Dateistände vorliegen zu haben (die Infos über die Daten liegen ja nicht unbedingt alle in einer Datei); etc. dürfte wohl höher sein, als das man mit einem Dump ernsthafte Probleme bekommt.
Und Risikominimierung sollte wohl eine Selbstverständlichkeit sein. (Ausser, man hat seinen Admin-Posten in der IT der Bundeswehr ...)

gruß,
wahsaga

[steckl]

Hi,

b) Der Vorteil eines Backups in Form von Dumps, anstatt die DB-Files direkt zu kopieren, ist es erstens, dass man nicht erst den Cache leeren muss und zweitens dass Dumps leichter kompatibel mit anderen mySql-Versionen sind.

Ein Nachteil wäre dann, dass man einen Dump erst wieder "einspielen" muss, was u.U. ziemlich zeitaufwendig sein kann - wohingegen "Dateien kopieren" bei angehaltenem Server fix gehen dürfte.

Stimmt, daran hab ich noch garnicht gedacht, aber so gross ist die DB nicht.

Aber "Dateien kopieren" ist eine Variante, bei der es eigentlich jeden Admin schaudern lassen sollte.
Die Wahrscheinlichkeit, etwas "kaputt zu machen"; ggf. nicht mehr zueinander passende Dateistände vorliegen zu haben (die Infos über die Daten liegen ja nicht unbedingt alle in einer Datei); etc. dürfte wohl höher sein, als das man mit einem Dump ernsthafte Probleme bekommt.

Das ist gut, werde ich auch noch in meine Praesentation einbauen :-)

Wie werden Backups eigentlich bei riseigen Datenbanken gemacht? Oder werden dort einfach nur mehrere redundante Server verwendet?

mfG,
steckl

[wahsaga]

hi,

Wie werden Backups eigentlich bei riseigen Datenbanken gemacht? Oder werden dort einfach nur mehrere redundante Server verwendet?

Da wird sicher eine mehrschichtige Strategie gefahren.

• RAID zur Erhöhung der Ausfallsicherung der HDDs im laufenden Betrieb dürfte eh mal selbstverständlich sein.
• ggf. Replikation/Spiegelung auf einen zweiten DB-Server; entweder bei jeder datenändernden Aktion getriggert, oder in regelmässigen Intervallen.
• Komplettkopien von HDDs sind auch denkbar; dürften wohl "kompatibler" auszutauschen sein, als einzelne Dateien, die ein DBMS benutzt, aber auch wiederum natürlich nur für den absoluten Notfall; dürften aber ein Anhalten des Systems erfordern, im laufenden Betrieb auch eher schwierig.

gruß,
wahsaga

[steckl]

Danke, damit wär schomal Punkt b) sogar mit Zusatzinfos geklärt :-)

mfG,
steckl