Re: [1/2 OT] MySQL Storage Files
Hallo Peter,
On Thu, Feb 17, 2005 at 10:21:51AM +0100, Peter Blancke wrote:
> Tu mir den Gefallen und versuche hier doch nicht, Sicherheit zu
> versprechen, die nicht vorliegt.
Das lag mir nicht im Sinn. Ein Transfer von Daten ist nie sicher. Egal,
ob es sich um eine SQL-Textdatei oder ein Binärformat handelt. Wobei
bei ersterer Datenverlusste unwichtige stellen treffen können.
> Sicherlich laesst sich empirisch
> beweisen, dass die Binaerkopie bei laufender Datenbank ueberlebt,
> aber wozu das?
siehe anderes Post, mysqlhotcopy macht genau dies - und es funktioniert
nicht nur empirisch sondern zuverlässig.
> Aussagen wie "ein shutdown ist sicherer, aber kein
> muss" helfen dem OP nicht weiter.
Wenn er keinen shutdown der DB machen kann, muss er sicherstellen, dass
alle Daten geschrieben wurden und muss die Tabelle(n) vor dem kopieren
sperren. Das ist wie ein shutdown.
> Der braucht einen reibungslosen
> Transfer seiner Datenbank und ich bleibe -- Erkenntnis aus Jahren in
> diesem Geschaeft -- dabei, dass der Dump immer noch die beste
> Methode ist.
"Erfahrung heißt gar nichts, man kann seine Sache auch 35 Jahre schlecht
machen", schrieb K.T. so vor 75-80 Jahren.
Aber Dein Posting von gestern war in einem Ton gehalten, der sagte: es
geht nicht anders als mit einem Dump. Und das ist falsch (beruhend auf
_meiner_ mehrjährigen Erfahrung - ja, auch im produktiven Umfeld mit
größeren Datenbanken).
> Das ist kein Spott. Nochmals: Gaukle dem OP nicht vor, dass der
> Transfer einfach nur ein simpler Kopierakt ist.
Prinzipell ist das so, man sollte wissen, ob man an alles gedacht hat,
bevor man Enter drückt.
> "nicht so zimperlich". Detlef Bosau wuerde jetzt sagen: "Hoer auf zu
> schwallen und komm mal auf den Punkt."
Ich habe die notwendigen Schritte für eine erfolgreiche Binärkopie
mehrfach aufgezählt.
> > und die Releases sind i.Allg. vollständig abwärtskompatibel.
>
> Dann sprichst Du von Einbahnstrassen. Vielleicht benoetigt der OP
> die Aufwaertskompatibilitaet.
Die wäre ihm bei der von Dir als obligatorisch erwähnten Beibehaltung
des Releases auch nicht gegeben, da ist doch die Möglichkeit eines
neueren Releases vorteilhafter. Welche Daten, die neue Features nutzen,
sind Abwärtskompatibel - und damit das Programm Aufwärtskompatibel?
Es ist nun einmal kaum möglich, Features von MySQL5 in MySQL3.23 zu
nutzen und es ist reiskant, solche Daten dort einzuspielen - andersrum
geht es normalerweise (MySQL5 habe ich noch nicht getestet,
3.23->4.0/4.1 ging bei meinen Tests fehlerfrei - die DB mysql lasse ich
natürlich als "Konfigurationsdatei" unberührt und vom Release
verwalten) - zwischen gleichen Releases aber auch kein Problem.
> Das ist Spott.
Latürnich.
> >> Das Ganze ist hoffentlich kein Produktivsystem.
> >
> > Ja und? Entweder funktioniert der Ansatz, und die neu geladene DB
> > arbeitet wie erwartet,
>
> Und wie soll er das pruefen? Er spricht von hunderten von Megabyte.
> Da wird er sich nicht jeden Datensatz einzeln anschauen wollen.
Nein, aber Tabellen öffnen. Dabei würden z.b. fehlerhafte Zugriffsrechte
auffallen oder eben korrupte Dateien, mit denen der MySQL-Server nichts
anfangen kann.
> > dann realisiert man das nach dem Testlauf,
>
> Beschreib doch dazu einmal eine Methode.
>
> Vielleicht diese: Export durch einen mysqldump und anschliessend
> eine MD5-Summe bei Vergleich mit einem frueheren Dump? Dann fangen
> wir langsam an, uns hier um unsere eigene Achse zu drehen, als dem
> OP zu helfen.
Hmm, ./check_alldatabases.sh?
SHOW DATABASES;
for i in ...
use i
SHOW TABLES;
for j in ...
DESCRIBE j, select count(*) - oder was auch immer.
done
done
> > Mit Deinen geschilderten Einschränkungen würde ich sofort zu einem
> > anderen DBMS wechseln, wenn nicht einmal Datentransfers möglich
> > wären.
>
> Doch, sie ist moeglich. Ich habe die Moeglichkeit in meinem ersten
> Beitrag genannt. Und ich bleibe dabei.
Siehste, will ich Dir auch nicht absprechen. Aber ich bleibe dabei, dass
ein Kopieren der Datenbanken auf file-ebene ebenso legitim ist und habe
aufgezeigt, dass dies mit z.B. mysqlhotcopy sogar bei laufendem
DB-Server funktioniert und von MySQL legitimiert wurde.
Wenn Du dumps erstellst, bitte. Aber behaupte nicht, dass ein cp
unsicherer wäre, ohne entsrechende Beweise zu liefern (die dann
hoffentlich zeigen, welcher Fehler gemacht wurde).
Solange MySQL dateibasiert Daten im Filesystem speichert, solange sollte
man diesen kleinen Vorteil auch nutzen. Ansonsten ist die Speicherung im
Dateisystem ja eher ein Nachteil von MySQL.
Für mich ist hier EOT. Ich enthalte mich ab sofort einer Fortführung des
Streitgespräches.
hagen
--
,''`. Hagen Kuehnel - http://HagK.de
: :' : Kopierschutz: Alle Texte sind mit Double-ROT13 verschlüsselt. UrhG §95d
`. `'` Die Umgehung des Kopierschutzes stellt eine Straftat dar. UrhG §95a
`-
Reply to: