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
`-
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
