Auf USB-Stick mitscreiben

Hallo,

ich hätte gerne, dass MySQL parallel zur HauptDB auf einen USB-Stick
mitschreibt (Linux).

Zum einen wegen Datensicherheit, wenn die Festplatte kaputt geht, zum
anderen weil ich die Daten hin und wieder auf nen anderen Rechner
übertragen muss.

Geht das? Wenn kein Stick angeschlossen/gemountet ist, darf das aber
nicht zu Problemen führen. Das ganze muss für den Anwender foolproof sein :)

Oder sollte ich besser per Cronjob einfach jede Minute einen mysqldump
machen?

Gruß

Bernhard

Re: Auf USB-Stick mitscreiben

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Auf USB-Stick mitscreiben

Bernhard Reinhardt schrieb:
> Hallo,
>=20
> ich hätte gerne, dass MySQL parallel zur HauptDB auf einen USB-Stick
> mitschreibt (Linux).

Ich könnt mir vorstellen, zwei Instanzen zu starten (frag nochmal wenn =

es eine Option ist), und die zweite als Replikat der Ersten anzulegen,=20
am Stick.

> Geht das? Wenn kein Stick angeschlossen/gemountet ist, darf das aber
> nicht zu Problemen führen.=20

Als Idee: die Replikation stoppen und starten, je nachdem ob der Stick=20
vorhanden ist.

> Oder sollte ich besser per Cronjob einfach jede Minute einen mysqldump
> machen?

Das ist Quatsch - die ganze DB wird währenddessen gelockt.

Zeit sparen kann man, wenn man zuerst ein mysqlhotcopy _ohne_ Indexe=20
macht, und von dem Hotcopy einen Dump.
Kostet bei meinen DB's (ca. 3-8Giga Daten und Indices) aber auch 10-15=20
sek Stillstand, das kann ich mir nur Nachts leisten.

In diesem Sinn könnte man auch permanent ein Replikat laufen lassen, un=
d=20
von diesem die Hotcopies auf den Stick machen.

Sicher bin ich mir auch nicht, ob ein Stick richtig viele=20
Schreib/Lesevorgänge aushält.

HTH Michael

Re: Auf USB-Stick mitscreiben

Bernhard Reinhardt wrote:
> Hallo,

Hallo Reinhardt,

>
> ich hätte gerne, dass MySQL parallel zur HauptDB auf einen USB-Stick
> mitschreibt (Linux).

Das ist in meinen Augen eine sehr komische Idee

>
> Zum einen wegen Datensicherheit, wenn die Festplatte kaputt geht, zum
> anderen weil ich die Daten hin und wieder auf nen anderen Rechner
> übertragen muss.

Sollte dieser andere Rechner auch im Netzwerk hängen würde ich dir
dringend MySQL-Replikation empfehlen. Das ist dann für beides gut was du
willst.

> Geht das? Wenn kein Stick angeschlossen/gemountet ist, darf das aber
> nicht zu Problemen führen. Das ganze muss für den Anwender foolproof sein :)

Was passiert wenn der Stick raus gezogen wird ?!

> Oder sollte ich besser per Cronjob einfach jede Minute einen mysqldump
> machen?
>
> Gruß

Wolfgang

>
> Bernhard

Re: Auf USB-Stick mitscreiben

Also um das etwas klarer zu machen: Es geht um eine Startkladde
(http://intern.akaflieg.uni-karlsruhe.de/~deffi/akaflieg/sta rtkladde/).

Die Datenbank wird wohl nie größer als 2MB werden und es erfolgen
vielleicht 200 Zugriffe/Tag.

Der Rechner wird outdoor und wohl an einer Autobatterie betrieben
werden. Es ist also mit Stromausfällen und der ein oder anderen
Erschütterung zu rechnen.

Es geht also primär um Datensicherheit. Es geht auch gar nicht so darum
den Zugriff, der 1 Sekunde vor dem Crash erfolgt, noch mitzunehmen,
sondern darum das System möglich schnell und einfach wieder herstellen
zu können. Gibt´s eigentlich irgendwelche Schalter, MySQL möglichst
robust gegen Stromausfälle zu machen (am besten ist ja, man muss erst
gar nichts reparieren)?

Netzwerk ist wohl keine Option.

Die Frage ist, ob ein USB-Stick eine Option ist. Wenn der abgezogen
wird, darf das MySQL nicht aus dem Tritt bringen.

Gruß

Bernhard

Re: Auf USB-Stick mitscreiben

On 2007-04-04, Bernhard Reinhardt wrote:
> Also um das etwas klarer zu machen: Es geht um eine Startkladde
> (http://intern.akaflieg.uni-karlsruhe.de/~deffi/akaflieg/sta rtkladde/).
>
> Die Datenbank wird wohl nie größer als 2MB werden und es erfolgen
> vielleicht 200 Zugriffe/Tag.
>
> Der Rechner wird outdoor und wohl an einer Autobatterie betrieben
> werden. Es ist also mit Stromausfällen und der ein oder anderen
> Erschütterung zu rechnen.
>
> Es geht also primär um Datensicherheit. Es geht auch gar nicht so darum
> den Zugriff, der 1 Sekunde vor dem Crash erfolgt, noch mitzunehmen,
> sondern darum das System möglich schnell und einfach wieder herstellen
> zu können.

Bei dem Lastprofil würde ich wohl regelmäßige mysqldump-Aufrufe
machen (in Ein-Munten-Abständen halte ich allerdings für übertreiben)

> Gibt´s eigentlich irgendwelche Schalter, MySQL möglichst
> robust gegen Stromausfälle zu machen (am besten ist ja, man muss erst
> gar nichts reparieren)?

Ja, die sind standardmäßig an.

> Die Frage ist, ob ein USB-Stick eine Option ist. Wenn der abgezogen
> wird, darf das MySQL nicht aus dem Tritt bringen.

Spricht auch für mysqldump.
Alternative wäre noch ein Snapshot-fähiges Dateisystem, und
dann die Mysql-Datendateien vom Snapshot(!) sichern.

Grüße,

Florian

Re: Auf USB-Stick mitscreiben

Bernhard Reinhardt wrote:
> Also um das etwas klarer zu machen: Es geht um eine Startkladde
> (http://intern.akaflieg.uni-karlsruhe.de/~deffi/akaflieg/sta rtkladde/).
>
> Die Datenbank wird wohl nie größer als 2MB werden und es erfolgen
> vielleicht 200 Zugriffe/Tag.
>
> Der Rechner wird outdoor und wohl an einer Autobatterie betrieben
> werden. Es ist also mit Stromausfällen und der ein oder anderen
> Erschütterung zu rechnen.

Warum bleibst du dabei nicht bei was einfachem wie SQLite?
Muss es unbedingt eine komplette SQL Datenbank sein?


> Gibt?s eigentlich irgendwelche Schalter, MySQL möglichst
> robust gegen Stromausfälle zu machen (am besten ist ja, man muss erst
> gar nichts reparieren)?

fsync angeschaltet lassen, Transaktionen nutzen. Dafür sorgen, das
die Platte entweder auch geschrieben hat, wenn sie "erfolgreich geschrieben"
meldet oder Batteriegebuffert arbeitet.

Halt alles, was man im ganz normalen Datenbankbetrieb auch für die
Sicherheit seiner Daten tut. Dort besteht das gleiche Problem:
Was passiert bei einem Stromausfall.


> Die Frage ist, ob ein USB-Stick eine Option ist. Wenn der abgezogen
> wird, darf das MySQL nicht aus dem Tritt bringen.

Was hier noch eine Frage ist: wie lange hält der Stick durch, wenn
die Datenbank da unregelmäßig drauf schreibt.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Auf USB-Stick mitscreiben

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Auf USB-Stick mitscreiben

On 2007-04-04, Andreas Kretschmer wrote:
> begin Florian Laws schrieb:
>> Alternative wäre noch ein Snapshot-fähiges Dateisystem, und
>> dann die Mysql-Datendateien vom Snapshot(!) sichern.
>
> Ist das dann in sich konsistent?

Ja, wenn alle Datendateien auf dem selben Filesystem liegen.

Ein Snapshot vom Filesystem (oder vom Volume Manager) friert
den Zustand des Dateisystems/Volumes zu genau diesem Zeitpunkt
ein, quasi als ob Du in diesem Moment den Netzstecker gezogen
hättest.

Da es eine zentrale Aufgabe eines Datenbanksystems ist, stets
einen konsistenten Zustand auf der Platte zu halten, sind die
Daten also auch im Falle eines Stromausfalls oder eben Snapshots
konsistent.

Grüße,

Florian

Re: Auf USB-Stick mitscreiben

Florian Laws schrieb:
> Da es eine zentrale Aufgabe eines Datenbanksystems ist, stets
> einen konsistenten Zustand auf der Platte zu halten, sind die
> Daten also auch im Falle eines Stromausfalls oder eben Snapshots
> konsistent.

Das ist sowohl auf Dateisystem- als auch auf Datenbankebene machbar,
allerdings muss man in beiden Fällen die richtigen Optionen auswählen,
sonst funktioniert die Sache nicht.

Das heißt:

Auf Dateisystemebene benötigst Du eins mit Journal. ext2 (bei vielen
Distributionen immer noch Standard) kann das nicht, beim Neustart hat
man erstmal eine Weile auf den Dateisystemcheck zu warten und hat dann
zwar etwas, das ein in sich konsistentes Dateisystem ist, aber die
einzelnen Dateien können dann durchaus die Stände von verschiedenen
Uhrzeiten enthalten.
Besser ext3. Ggf. auch reiserfs. Ich glaube, jfs ist ebenfalls geeignet,
bin mir aber nicht sicher. xfs ist definitiv ungeeignet, wenn man
Ausfälle *erwartet*.
Sollte es ein Windows-System sein, dann NTFS. Ob NTFS ausreicht, weiß
ich nicht, aber etwas besseres kriegt man wahrscheinlich nicht (es
*könnte* die anderen Treiber auch für Windows geben, aber Windows ist
für diese Art des Betriebs rein grundsätzlich nicht ausgelegt).

Für die Datenbank benötigst Du eine mit ACID-Eigenschaften. Bei mysql
heißt das ziemlich alternativlos "InnoDB mit Transaktionen". Jede Gruppe
von Befehlen, die ganz oder gar nicht Wirkung haben sollen, mit den Befehlen
BEGIN
...
COMMIT
umschließen, und gut ist.
Myisam-Tabellen (die sind meistens als Default eingestellt) sind
grundsätzlich ungeeignet, damit kann es Dir passieren, dass in einer
Tabelle alle Änderungen drin sind und in einer anderen nicht.

Re: Auf USB-Stick mitscreiben

On 2007-04-04, Joachim Durchholz wrote:
> Florian Laws schrieb:
>> Da es eine zentrale Aufgabe eines Datenbanksystems ist, stets
>> einen konsistenten Zustand auf der Platte zu halten, sind die
>> Daten also auch im Falle eines Stromausfalls oder eben Snapshots
>> konsistent.
>
> Das ist sowohl auf Dateisystem- als auch auf Datenbankebene machbar,
> allerdings muss man in beiden Fällen die richtigen Optionen auswählen,
> sonst funktioniert die Sache nicht.
>
> Das heißt:
>
> Auf Dateisystemebene benötigst Du eins mit Journal. ext2 (bei vielen
> Distributionen immer noch Standard) kann das nicht, beim Neustart hat
> man erstmal eine Weile auf den Dateisystemcheck zu warten und hat dann
> zwar etwas, das ein in sich konsistentes Dateisystem ist, aber die
> einzelnen Dateien können dann durchaus die Stände von verschiedenen
> Uhrzeiten enthalten.

Warum ist das so, wo doch das Datenbanksystem sicherstellt, dass
beim COMMIT alle Daten in den Schreibcaches auf Platte landen?

> Sollte es ein Windows-System sein, dann NTFS. Ob NTFS ausreicht, weiß
> ich nicht, aber etwas besseres kriegt man wahrscheinlich nicht (es
> *könnte* die anderen Treiber auch für Windows geben, aber Windows ist
> für diese Art des Betriebs rein grundsätzlich nicht ausgelegt).

Unsinn.

(Windows hat allerdings meines Wissens kein Snapshot-Feature,
kann man aber evt. mit Veritas Volume Manager o.ä. nachrüsten.9

Grüße,

Florian

Re: Auf USB-Stick mitscreiben

Florian Laws wrote:
> On 2007-04-04, Joachim Durchholz wrote:
>>
>> Auf Dateisystemebene benötigst Du eins mit Journal. ext2 (bei vielen
>> Distributionen immer noch Standard) kann das nicht, beim Neustart hat
>> man erstmal eine Weile auf den Dateisystemcheck zu warten und hat dann
>> zwar etwas, das ein in sich konsistentes Dateisystem ist, aber die
>> einzelnen Dateien können dann durchaus die Stände von verschiedenen
>> Uhrzeiten enthalten.
>
> Warum ist das so, wo doch das Datenbanksystem sicherstellt, dass
> beim COMMIT alle Daten in den Schreibcaches auf Platte landen?

Du weisst, in welcher Gruppe wir uns befinden? Gut.

Bei welcher Datenbank ist es denn üblich, aus Performancefragen
so Sachen wie fsync ausser Acht zu lassen?

Joachim hat auch nur die Möglichkeiten aufgezählt, wie man das
Problem des OP realisieren kann.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Auf USB-Stick mitscreiben

Florian Laws schrieb:
>> Auf Dateisystemebene benötigst Du eins mit Journal. ext2 (bei vielen
>> Distributionen immer noch Standard) kann das nicht, beim Neustart hat
>> man erstmal eine Weile auf den Dateisystemcheck zu warten und hat dann
>> zwar etwas, das ein in sich konsistentes Dateisystem ist, aber die
>> einzelnen Dateien können dann durchaus die Stände von verschiedenen
>> Uhrzeiten enthalten.
>
> Warum ist das so, wo doch das Datenbanksystem sicherstellt, dass
> beim COMMIT alle Daten in den Schreibcaches auf Platte landen?

Weil das Datenbanksystem seine Daten auch nur ans Dateisystem
weiterreicht. Wenn das Dateisystem beschließt, mit dem Rausschreiben
noch ein bisschen zu warten, kann es dort doch wieder zu Inkonsistenzen
kommen.
Dateisysteme mit Journal geben für solche Fälle Garantien ab, die man
bei Dateisysteme ohne Journal kaum hat. Man kann natürlich die Platte
mit der sync-Option mounten, aber dann wird's eklig langsam.

Geht es nur darum, den USB-Stick abzusichern, könnte sync allerdings
tatsächlich eine Möglichkeit sein. Man hat dann zwar wesentlich mehr
Schreibvorgänge auf Hardwareebene, was die Sache immer noch verzögert
und zudem tendenziell die Lebensdauer des Flash-Speichers reduziert,
deshalb würde ich das testen wollen - aber diese Nachteile sind nicht so
katastrophal wie bei einer Festplatte, wo Zugriffe auf weit
auseinanderliegende Plattenbereiche einen derartigen Performanceverlust
ausmachen, dass man die Zugriffe schon umordnen *muss*.

>> Sollte es ein Windows-System sein, dann NTFS. Ob NTFS ausreicht, weiß
>> ich nicht, aber etwas besseres kriegt man wahrscheinlich nicht (es
>> *könnte* die anderen Treiber auch für Windows geben, aber Windows ist
>> für diese Art des Betriebs rein grundsätzlich nicht ausgelegt).
>
> Unsinn.

Kein Unsinn.
Es ist natürlich nicht unmöglich, Windows so zu betreiben, aber ich würd
trotzdem davon abraten: wenn man nach Stromausfall und Neustart erstmal
zehn Minuten warten muss, bis die Dateisystemprüfung durch ist, macht
das einfach keinen Spaß.
Vor, sagen wir, zehn Jahren wär das noch akzeptabel gewesen, aber
mittlerweile ermöglichen Journal-Dateisysteme einen praktisch sofortigen
Neustart.

> (Windows hat allerdings meines Wissens kein Snapshot-Feature,
> kann man aber evt. mit Veritas Volume Manager o.ä. nachrüsten.9

Ah, interessant, dass es sowas auch für Windows geht.
Wobei es mir gar nicht mal um Snapshots ging (die aber auf ihre Weise
ebenfalls interessant sind).

Grüße
Jo

Re: Auf USB-Stick mitscreiben

Joachim Durchholz schrieb:

> Florian Laws schrieb:
>
>>> Sollte es ein Windows-System sein, dann NTFS. Ob NTFS ausreicht, weiß
>>> ich nicht, aber etwas besseres kriegt man wahrscheinlich nicht (es
>>> *könnte* die anderen Treiber auch für Windows geben, aber Windows ist
>>> für diese Art des Betriebs rein grundsätzlich nicht ausgelegt).
>>
>> Unsinn.
>
> Kein Unsinn.

Kommt jetzt darauf an, was konkret Du meinst. Windows ist von Haus aus
für den Serverbetrieb in der Tat nicht besonders gut geeignet, auch wenn
Kleinstweich schon aus Prinzip etwas Anderes behauptet.

> Es ist natürlich nicht unmöglich, Windows so zu betreiben, aber ich würd
> trotzdem davon abraten: wenn man nach Stromausfall und Neustart erstmal
> zehn Minuten warten muss, bis die Dateisystemprüfung durch ist, macht
> das einfach keinen Spaß.

Welche Uralt-Version von Windows benutzt Du? Mein XP hat - auch nach
Stromausfall - noch nie eine Dateisystemprüfung durchgeführt, und auch
manuell von mir angestoßene Prüfungen (ca. 1x im Monat) brauchten auf
meinem 1-GHz-P-III keine 10 Minuten (bei ca. 140.000 Dateien in 33.732
Verzeichnissen auf 10 NTFS-Partitionen) und haben bisher auch noch nie
einen Fehler gefunden.

> Vor, sagen wir, zehn Jahren wär das noch akzeptabel gewesen, aber
> mittlerweile ermöglichen Journal-Dateisysteme einen praktisch sofortigen
> Neustart.

NTFS _ist_ ein Journal-Dateisystem.

Gruß. Claus

Re: Auf USB-Stick mitscreiben

On 2007-04-06, Joachim Durchholz wrote:
> Florian Laws schrieb:
>>> Auf Dateisystemebene benötigst Du eins mit Journal. ext2 (bei vielen
>>> Distributionen immer noch Standard) kann das nicht, beim Neustart hat
>>> man erstmal eine Weile auf den Dateisystemcheck zu warten und hat dann
>>> zwar etwas, das ein in sich konsistentes Dateisystem ist, aber die
>>> einzelnen Dateien können dann durchaus die Stände von verschiedenen
>>> Uhrzeiten enthalten.
>>
>> Warum ist das so, wo doch das Datenbanksystem sicherstellt, dass
>> beim COMMIT alle Daten in den Schreibcaches auf Platte landen?
>
> Weil das Datenbanksystem seine Daten auch nur ans Dateisystem
> weiterreicht. Wenn das Dateisystem beschließt, mit dem Rausschreiben
> noch ein bisschen zu warten, kann es dort doch wieder zu Inkonsistenzen
> kommen.
> Dateisysteme mit Journal geben für solche Fälle Garantien ab, die man
> bei Dateisysteme ohne Journal kaum hat. Man kann natürlich die Platte
> mit der sync-Option mounten, aber dann wird's eklig langsam.

Oder einfach fsync(2) aufrufen,
genau dafür ist dieser Systemcall nämlich da.

Die meisten Journalling-Dateisysteme garantieren übrigens nur
Konsistenz des Dateisystems selbst, nicht aber der Nutzdaten.

> Geht es nur darum, den USB-Stick abzusichern, könnte sync allerdings
> tatsächlich eine Möglichkeit sein. Man hat dann zwar wesentlich mehr
> Schreibvorgänge auf Hardwareebene, was die Sache immer noch verzögert
> und zudem tendenziell die Lebensdauer des Flash-Speichers reduziert,
> deshalb würde ich das testen wollen - aber diese Nachteile sind nicht so
> katastrophal wie bei einer Festplatte, wo Zugriffe auf weit
> auseinanderliegende Plattenbereiche einen derartigen Performanceverlust
> ausmachen, dass man die Zugriffe schon umordnen *muss*.

Reordering von Zugriffen auf der Festplatte ist auch keine
Aufgabe des Dateisystems.

>>> Sollte es ein Windows-System sein, dann NTFS. Ob NTFS ausreicht, weiß
>>> ich nicht, aber etwas besseres kriegt man wahrscheinlich nicht (es
>>> *könnte* die anderen Treiber auch für Windows geben, aber Windows ist
>>> für diese Art des Betriebs rein grundsätzlich nicht ausgelegt).
>>
>> Unsinn.
>
> Kein Unsinn.
> Es ist natürlich nicht unmöglich, Windows so zu betreiben, aber ich würd
> trotzdem davon abraten: wenn man nach Stromausfall und Neustart erstmal
> zehn Minuten warten muss, bis die Dateisystemprüfung durch ist, macht
> das einfach keinen Spaß.
> Vor, sagen wir, zehn Jahren wär das noch akzeptabel gewesen, aber
> mittlerweile ermöglichen Journal-Dateisysteme einen praktisch sofortigen
> Neustart.

Wie gut, dass Windows NT seit 1993 mit einem Journalling-Dateisystem
(NTFS) ausgeliefert wird.

Grüße,

Florian

Re: Auf USB-Stick mitscreiben

Florian Laws schrieb:
> On 2007-04-06, Joachim Durchholz wrote:
>> Dateisysteme mit Journal geben für solche Fälle Garantien ab, die man
>> bei Dateisysteme ohne Journal kaum hat. Man kann natürlich die Platte
>> mit der sync-Option mounten, aber dann wird's eklig langsam.
>
> Oder einfach fsync(2) aufrufen,
> genau dafür ist dieser Systemcall nämlich da.

Hmm... macht InnoDB das?
Ich hatte bisher den Eindruck, es verlässt sich auf das Dateisystem,
fsync kann ja ein ziemlicher Performancefresser sein; wenn man ein
Journalling Filesystem hat, würde ich sogar darauf verzichten wollen
(fsync gibt einem dann womöglich Garantien, die man gar nicht braucht,
und muss dafür Dinge tun, die unnötig Performance fressen).
Das geht jetzt allerdings ein Stück weit in Details hinein, wo ich
schlicht nicht mehr genau genug Bescheid weiß.

> Die meisten Journalling-Dateisysteme garantieren übrigens nur
> Konsistenz des Dateisystems selbst, nicht aber der Nutzdaten.

Es ist für ein Dateisystem gar nicht möglich, die Konsistenz der
Nutzdaten zu garantieren.
Außer, es bietet den Anwendungsprogrammen eine Möglichkeit, Beginn und
Ende einer Transaktion zu signalisieren. (Leider ist das kein Teil der
standardisierten Dateischnittstellen...)

>> Geht es nur darum, den USB-Stick abzusichern, könnte sync allerdings
>> tatsächlich eine Möglichkeit sein. Man hat dann zwar wesentlich mehr
>> Schreibvorgänge auf Hardwareebene, was die Sache immer noch verzögert
>> und zudem tendenziell die Lebensdauer des Flash-Speichers reduziert,
>> deshalb würde ich das testen wollen - aber diese Nachteile sind nicht so
>> katastrophal wie bei einer Festplatte, wo Zugriffe auf weit
>> auseinanderliegende Plattenbereiche einen derartigen Performanceverlust
>> ausmachen, dass man die Zugriffe schon umordnen *muss*.
>
> Reordering von Zugriffen auf der Festplatte ist auch keine
> Aufgabe des Dateisystems.

Mag sein - aber das Dateisystem muss auf das Reordering zumindest
Einfluss nehmen können.
Und sei es nur durch Abschalten (sync-Option)...

>>>> Sollte es ein Windows-System sein, dann NTFS. Ob NTFS ausreicht, weiß
>>>> ich nicht, aber etwas besseres kriegt man wahrscheinlich nicht [...]
>
> Wie gut, dass Windows NT seit 1993 mit einem Journalling-Dateisystem
> (NTFS) ausgeliefert wird.

Ah, dann kann ich "ob NTFS ausreicht, weiß ich nicht" durch "NTFS reicht
dann auch aus" ersetzen.

Grüße
Jo

Re: Auf USB-Stick mitscreiben

Joachim Durchholz!

> Hmm... macht InnoDB das?

Ja. Wenn man von Details absieht wie z.B. dass es unter Windows nicht
fsync() heißt, aber natürlich auch existiert.

Man kann es auch ausschalten, default ist aber an.


Gruß
Daniel