| 1 |
Jan Riedel wrote: |
| 2 |
> Sebastian van de Meer wrote: |
| 3 |
>> Hallo Liste.... |
| 4 |
>> |
| 5 |
>> Ist es unter einem mysql-System sinnvoll den cache am Raid-controller |
| 6 |
>> zu deaktivieren und in somit zu zwingen alle Daten sofort auf die |
| 7 |
>> Platten zu schreiben? |
| 8 |
> also den cache am controller abschalten ist meiner meinung nach keine |
| 9 |
> gute idee. ich habe das mal bei meinem controller gemacht und die |
| 10 |
> performance ging absolut in den keller. ich habe die genauen zahlen |
| 11 |
> nicht mehr da, aber die schreibperformance war vollkommen inakzeptabel. |
| 12 |
|
| 13 |
Das dachte ich mir auch... |
| 14 |
|
| 15 |
> wenn du angst hast, dass die daten, die der controller noch im cache |
| 16 |
> hatte nach einem stromausfall futsch sind, solltest du vielleicht die |
| 17 |
> kohle fuer eine evtl. fuer den controller verfuegbare battery backup |
| 18 |
> unit ausgeben. was hast du denn fuer einen controller? |
| 19 |
|
| 20 |
Solange der Controller write barriers oder wenigstens Cache Flushes |
| 21 |
beherrscht, sollte MySQL die Daten so ablegen können, dass der Kram auf |
| 22 |
der Platte zumindest soweit konsistent ist, dass er wiederhergestellt |
| 23 |
werden kann, wenn der Dämon nach einem kalten Neustart wieder hochkommt. |
| 24 |
|
| 25 |
Bleibt die Frage, wie weit du MySQL traust*, und welche Speicherengine |
| 26 |
du verwendest. |
| 27 |
|
| 28 |
LG, |
| 29 |
T. |
| 30 |
|
| 31 |
*Nicht lachen, es gibt Leute, die tun das. |
| 32 |
-- |
| 33 |
gentoo-user-de@g.o mailing list |
Archives