[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [1/2 OT] MySQL Storage Files



Hallo Hagen,

Hagen Kuehnel schrieb:

Was soll dieser Spott.

Danke.

>>Das Ganze ist hoffentlich kein Produktivsystem.

Leider schon. Aus diesem Grund soll der Server auch stillgelegt werden. Wir waren vorher nicht zuständig.

> Replikation?

Mittel der Wahl, seh ich auch so.

-> weiter in anderer Mail ontopic. :)

Andi

On Wed, Feb 16, 2005 at 08:40:54PM +0100, Peter Blancke wrote:

Andreas Brandl <debian-mailinglist@andreas-brandl.de> dixit:

Peter Blancke schrieb:

Andreas Brandl <debian-mailinglist@andreas-brandl.de> dixit:

Der Umzug darf nicht binaer erfolgen; fuehre folglich mit
mysqldump einen SQL-Dump Deiner Datenbank(en) durch. Dieser Dump
laesst sich dann entsprechend komprimieren und auf den neuen
Server verfrachten.

ok, ist hier leider nicht möglich, da der "glumpige" Server den
Geist aufgibt angesichts der Datenmenge bzw. CPU-Auslastung.


nice hilft hier sicher, bei 'alten' Kisten ist es meist I/O, was die Last
verursacht.


Und: Wenn Du Dich nicht mit mysqldump befasst, wie sicherst Du denn
dann Deine Dateien? Bei laufendem Server? Oder gar nicht? *schauder*


Replikation?

Mindestens muss der mysql-Daemon beendet werden, wenn es denn schon
die Binaerdateien sein muessen, die Du anfasst.


Muss, muss gar nichts. Zugriffe, vor allem schreibende, sllten auf die
zu kopierende Datenbank unterbunden werden. Ein shutdown ist sicherer,
aber kein muss.


Grau ist alle Theorie:


Das übliche, Probleme wegen Spezialitäten kann es immer geben.


Theoretisch ist es tatsaechlich egal, wenn Du
gewaehrleisten kannst, dass die SQL-Server nicht nur gleiche
Versionsnummern haben, sondern auch mit den gleichen Parametern
kompiliert wurden, sprich, auch die Programme des SQL-Servers bis
aufs letzte Bit identisch sind.


Was soll dieser Spott. MySQL ist im Gegensatz zu den großen RDBMS nicht
so zimperlich und die Releases sind i.Allg. vollständig
abwärtskompatibel. "Bis aufs letzte Bit" - wahrscheinlich sollen Deiner
Meinung nach auch die Maschinen völlig identisch sein, darf der RAM oder
die CPU oder MassStorage nie aufgerüstet werden. *Kopfschüttel*


Das Ganze ist hoffentlich kein Produktivsystem.


Ja und? Entweder funktioniert der Ansatz, und die neu geladene DB
arbeitet wie erwartet, dann realisiert man das nach dem Testlauf, oder
man muss eine andere Lösung evaluieren. Mit Deinen geschilderten Einschränkungen würde ich sofort zu einem
anderen DBMS wechseln, wenn nicht einmal Datentransfers möglich wären.




Reply to: