Hallo

ptk+2007-08-30 22:42:27--

Kannst du die Stelle zeigen, bei der die Datensicherheit von InnoDB kommentiert wurde?

InnoDB Wikipedia

Gruss
Kristian

kristian+2007-08-31 09:53:24--

Hallo

ptk+2007-08-30 22:42:27--

Kannst du die Stelle zeigen, bei der die Datensicherheit von InnoDB kommentiert wurde?

InnoDB Wikipedia

Gruss
Kristian

Das was da steht gilt aber genauso für MyISAM.

Der Text zeigt nur das die Verwendung von Transaktionen nicht 100%ige Sicherheit bedeutet, und das es noch von dem OS abhängt. Das es schlechter ist als gar keine Transaktionen (MyISAM) davon steht dort nichts.

Wenn man 100%ige Transaktionssicherheit möchte in Bezug
auf Cache etc dann wären Raw Devices und die Umgehung des
Festplattencaches optimal, aber ich glaube nicht, dass MySQL
das kann bzw. ob es dann nicht Probleme mit Backups gibt.

Aber korrekt ist, dass InnoDB sicherer ist als MyISAM.

Ent2/3 kann man mit der Option "sync" mounten, damit wird alles direkt geschrieben und gelesen ohne Cache. (Postgresql warnt übrigens wenn das nicht der Fall ist...)

Hallo

Schön mal wieder was zu lernen :-)
Den einzigen Nachteil den ich - nach ein bisschen Lesen der Doku - für innoDB sehe ist:
"InnoDB-Tabellen unterstützen keine FULLTEXT-Indizes."

Das finde ich schade, ich hatte mich gestern so gefreut, dieses Feature bei MyISAM zu entdecken.

Gruss
Kristian

Gast+2007-08-31 11:02:58--

Ent2/3 kann man mit der Option "sync" mounten, damit wird alles direkt geschrieben und gelesen ohne Cache. (Postgresql warnt übrigens wenn das nicht der Fall ist...)

Wofür gibt es denn commit? Ein sync zusätzlich nach jeder Transaktion
halte ich für unschön und stellt noch immer nicht 100% sicher, dass die
Daten auch wirklich auf der Festplatte gelandet sind... zuerst liegen die
nämlich im Schreibcache der Festplatte... Ein Raid Controller kann hier
zusätzlich die Stromversorgung durch eine Batterie sicherstellen und
das nach einem Crash die Daten auf die Platte geschrieben werden,
aber schöner ist, dass die Datenbank sicherstellt, dass die Daten tatsächlich
auf der Festplatte liegen.

Edit: da hab ich wohl was vor den augen gehabt und das "mount" nicht gelesen!
sorry sid :-)

Für PostgreSQL muss das Dateisystem auch nicht mit der sync-Option gemounted sein. PostgreSQL warnt nur davor, die fsync-Option im Normalbetrieb abzuschalten.
Ein Raid-Controller mit Batterie-Puffer ist natürlich nie schlecht.
Generell würde ich bei MySQL, wenns um Datensicherheit geht, auch InnoDB bevorzugen. Das ist zwar eventuell ein wenig langsamer und braucht, wenn ich das noch richtig im Kopf habe, auch ein wenig mehr Platz auf der Platte, doch wie gesagt, wenns um die Datensicherheit geht und man Transaktionen benötigt führt da kein Weg dran vorbei.

bloonix+2007-08-31 12:35:36--

Gast+2007-08-31 11:02:58--

Ent2/3 kann man mit der Option "sync" mounten, damit wird alles direkt geschrieben und gelesen ohne Cache. (Postgresql warnt übrigens wenn das nicht der Fall ist...)

Wofür gibt es denn commit? Ein sync zusätzlich nach jeder Transaktion
halte ich für unschön und stellt noch immer nicht 100% sicher, dass die
Daten auch wirklich auf der Festplatte gelandet sind... zuerst liegen die
nämlich im Schreibcache der Festplatte... Ein Raid Controller kann hier
zusätzlich die Stromversorgung durch eine Batterie sicherstellen und
das nach einem Crash die Daten auf die Platte geschrieben werden,
aber schöner ist, dass die Datenbank sicherstellt, dass die Daten tatsächlich
auf der Festplatte liegen.

Die Datenbank soll sicherstellen das die Daten wirklich auf der festplatte liegen? Wie soll es das tun? Dann müssten MySQL, PostgreSQL etc. ja IDE,SCSI,... Treiber in den Datenbanken integrieren damit soetwas möglich ist.

Das OS Regelt ob Dateien direkt geschrieben werden oder nicht. und wenn du eine Partition mit "sync" mountest dann heißt es nicht das nach jeder Operation gesynct wird. Sondern das das OS Synchrone Schreibzugriffe macht, anstatt default asynchrone.

Das heißt das OS meldet erst dann der DB ein "ok" zurück wenn das OS von sich aus gesehen die Daten auch auf die festplatte geschrieben hat. Vorher gibt es kein "ok" und die "db" muss warten. bei "asyncron" was default ist, bekommt die db schneller ein ok, das wirkliche Speichern kann aber später pasieren. async ist also Performanter, aber zu lasten von datensicherheit.

sync bedeutet so jedenfalls nicht, das geschrieben wird, und danach erst gesynct.


Ansonsten würde ich deswegen aber nicht async ausschalten. Und in Serverumgebungen sollte sowieso eine USV davor sein, so das auch ein Stromausfall nicht den PC sofort ausschaltet.

sid burn+2007-08-31 16:22:52--

Die Datenbank soll sicherstellen das die Daten wirklich auf der festplatte liegen? Wie soll es das tun? Dann müssten MySQL, PostgreSQL etc. ja IDE,SCSI,... Treiber in den Datenbanken integrieren damit soetwas möglich ist.

Das OS Regelt ob Dateien direkt geschrieben werden oder nicht. und wenn du eine Partition mit "sync" mountest dann heißt es nicht das nach jeder Operation gesynct wird. Sondern das das OS Synchrone Schreibzugriffe macht, anstatt default asynchrone.

Das heißt das OS meldet erst dann der DB ein "ok" zurück wenn das OS von sich aus gesehen die Daten auch auf die festplatte geschrieben hat...

Genau das alles möchte man doch eigentlich garnicht.

Um so mehr Caches es gibt, um so höher ist die Chance,
dass es bei einem Absturz inkonsistente Daten gibt.
Die meisten professionellen Datenbanken haben ihren
eigenen Cache in dem die Datenbankblöcke gecached
werden, selbst MySQL unterstützt dieses "Feature" mittler-
weile mit InnoDB.

Szenario:

Eine Transaktion wird commitet und die Datenbank möchte die
"Dirty Blocks" aus dem eigenen Cache auf die Platte schreiben.
Die Daten wandern dann zunächst einmal in den Filesystemcache.
Dort werden die "Dirty Blocks" wiederrum in bestimmten Intervallen
auf die Platte geschrieben, aber die "Dirty Blocks" landen dann
wiederrum erstmal im Schreibcache der Festplatte. Die Datenbank
erhält aber schonmal ein ACK und schreibt die Transaktion als commited
in die Transaktionslogs. Wenn nun in diesem Moment der Server
crashed, sind die Daten weg bzw die Daten sind inkonsistent,
weil die Daten gegebenfalls noch nicht aus dem Festplattencache
auf die Platte geschrieben wurden oder nur teilweise. Um das zu
verhindern, kann man zum einem Raw Devices verwenden,
um den Filesystemcache zu umgehen. Zusätzlich muss sichergestellt
werden, dass die Daten im Festplattencache auf jedem Fall auch
physikalisch auf der Platte landen wie zum Beispiel mit Raid Controllern
und einer BBU. Erst dann darf die Datenbank die Transaktion als
commitet in die Transaktionslogs notieren, um dann bei einem Crash
gegebenfalls ein Recovery durchzuführen.

bloonix+2007-08-31 18:30:31--

Die Daten wandern dann zunächst einmal in den Filesystemcache.

obwohl ich hier nicht ganz 100% sicher bin, wie es mit sync etc ausschaut.