Hi,
auf einem Server passierte neulich etwas Merkwürdiges: Eine InnoDB-Tabelle war nach einem Ausflug ins Rescue korrupt und ließ sich nicht reparieren. Da er ein Slave ist, habe ich die Replikation einfach neu aufgesetzt.
Im erwähnten Rescue-Ausflug war mir aufgefallen, dass ein RAID-Check den Wert in /sys/block/md2/md/mismatch_cnt auf beachtliche Höhen katapultierte, was ich allerdings auf frühere Abstürze des Systems schob. Nach einem Repair des RAIDs war zunächst wieder alles in Ordnung; erneuter Check => 0 Mismatches.
Aber MySQL war halt hinüber - wohl, weil der RAID-Resync bei Mismatches nicht wirklich wissen kann, welche der beiden Platten nun "recht" hat...
Zwei Tage später: Wieder 148224 Mismatches nach einem RAID-Check. Und ich habe nun auch die Fehlerursache finden können: Die Mismatches steigen nach einem (periodisch laufenden) fstrim auf den Mountpoint des Softraids (welches somit aus zwei SSDs besteht, klar).
Was tun? Ist dieses Verhalten etwa "normal"? Es läuft übrigens ein 3.10er-Kernel unter Debian Squeeze.
Mich stört hier primär, dass ich bei Hardware-bedingten Mismatches nichts mit einem echo repair > /sys/block/md2/md/sync_action gerade biegen kann, ansonsten würden sie mich ja gar nicht stören (da der 'check' bereits richtige Lesefehler durch erneutes Schreiben des Sektors fixt).
Viele Grüße
Tim
auf einem Server passierte neulich etwas Merkwürdiges: Eine InnoDB-Tabelle war nach einem Ausflug ins Rescue korrupt und ließ sich nicht reparieren. Da er ein Slave ist, habe ich die Replikation einfach neu aufgesetzt.
Im erwähnten Rescue-Ausflug war mir aufgefallen, dass ein RAID-Check den Wert in /sys/block/md2/md/mismatch_cnt auf beachtliche Höhen katapultierte, was ich allerdings auf frühere Abstürze des Systems schob. Nach einem Repair des RAIDs war zunächst wieder alles in Ordnung; erneuter Check => 0 Mismatches.
Aber MySQL war halt hinüber - wohl, weil der RAID-Resync bei Mismatches nicht wirklich wissen kann, welche der beiden Platten nun "recht" hat...
Zwei Tage später: Wieder 148224 Mismatches nach einem RAID-Check. Und ich habe nun auch die Fehlerursache finden können: Die Mismatches steigen nach einem (periodisch laufenden) fstrim auf den Mountpoint des Softraids (welches somit aus zwei SSDs besteht, klar).
Was tun? Ist dieses Verhalten etwa "normal"? Es läuft übrigens ein 3.10er-Kernel unter Debian Squeeze.
Mich stört hier primär, dass ich bei Hardware-bedingten Mismatches nichts mit einem echo repair > /sys/block/md2/md/sync_action gerade biegen kann, ansonsten würden sie mich ja gar nicht stören (da der 'check' bereits richtige Lesefehler durch erneutes Schreiben des Sektors fixt).
Viele Grüße
Tim
