Re: [1/2 OT] MySQL Storage Files
Hagen Kuehnel <debian@hagk.de> dixit:
> On Wed, Feb 16, 2005 at 07:56:37PM +0100, Peter Blancke wrote:
>
>> Der Umzug darf nicht binaer erfolgen;
>
> Was ist denn das für eine falsche Aussage? Das stimmt nicht,
> nachzulesen unter dev.mysql.com
Da mag manches stehen.
Vertraue mir: Hier sprechen viele Jahre von Erfahrungen mit
Datenbanken und deren Binaerkopien. Das setzt sich auch unter
anderen SQL-Serversystemen fort. Es war bisher immer die sicherste
Methode, einen Dump zu transportieren. Binaertransporte haben oft
genug den Geist aufgegeben, auch nach Deinen Flush- oder
Sync-Empfehlungen, die Du hier aussprichst.
> der Dump macht sehr viel overhead und er dauert länger als ein
> binäres Kopieren.
Ich will mal nicht in Abrede stellen, dass das so auf Deinen
Maschinen ist. Das ist sicherlich eine Frage der augenblicklichen
technischen Situation. Ich habe das jeenfalls bisher noch nie
erfahren.
> Wartungsfenster. Ein weiterer Nachteil bei Änderung des DB-Release
> ist, dass sein Dump eventuell nicht mehr so einfach eingespielt
> werden kann, weil neue Keywords nicht escaped werden.
Das ist gang und gaebe. Und ja: sed, awk und Konsorten existieren.
Und man wird gleich vertraut mit moeglichen Aenderungen des neuen
Systems, in welches man sich ohnehin einarbeiten muss.
> _Kann_, deswegen löscht man ja die alte DB nicht sofort ;)
Das versteht sich wohl von selbst.
>> Die Groesse dieser Dateien hat nichts gemeinsam mit den
>> eigentlichen von Dir dort hineingefuetterten Daten.
>
> Soll das heißen, dass die größe nicht _identisch_ ist, mit den
> ursprünglich an die DB übergebene Datenmenge?
Nein. Sie ist nicht identisch.
Sie mag proportional mit der Datenmenge mitwachsen, das steht nicht
in Abrede und versteht sich von selber.
Beweis:
,----[ root@dbserver:/var/lib/mysql/bestellungen# xxd verlag.MYD ]
|
| 0000000: 0500 7d00 6b00 0000 0000 0001 30ee 0300 ..}.k.......0...
| 0000010: fe01 0000 000f 4d61 726b 7420 2620 5465 ......Markt & Te
| 0000020: 6368 6e69 6b2e 4d61 726b 7420 2620 5465 chnik.Markt & Te
| 0000030: 6368 6e69 6b20 4275 6368 2d20 756e 6420 chnik Buch- und
| [...]
| 00000d0: 7777 2e62 6876 2e6e 6574 0000 1128 3020 ww.bhv.net...(0
| 00000e0: 3231 2033 3129 2037 3635 2d31 3031 0000 21 31) 765-101..
| 00000f0: 0300 3b01 fe03 00fe 0300 0000 046d 6974 ..;..........mit
| 0000100: 700b 6d69 7470 2d56 6572 6c61 6700 0004 p.mitp-Verlag...
| 0000110: 426f 6e6e 0b77 7777 2e6d 6974 702e 6465 Bonn.www.mitp.de
| 0000120: 0c6d 6974 7040 6d69 7470 2e64 6500 0000 .mitp@mitp.de...
| 0000130: 0900 1202 6368 656e 0a77 7777 2e6d 7574 ....chen.www.mut
| 0000140: 2e64 6500 0000 0000 0300 161e fe03 00fe .de.............
| 0000150: 0800 0000 0550 6970 6572 0000 0000 0000 .....Piper......
| 0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
| 0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
| 0000180: 0300 1b0d fe03 00fe 0600 0000 0a46 6973 .............Fis
| 0000190: 6368 6572 2054 6200 0000 0000 0000 0000 cher Tb.........
`----
Da stehen folglich mehr Daten drin als die "ursprünglich an die DB
übergebene Datenmenge".
Gruss
Peter Blancke
--
Hoc est enim verbum meum!
Reply to: