linux user group brescia

immagine del castello

Archivio della mailing list

[LugBS] Disco corrotto a causa di MySql

Andrea Gelmini andrea.gelmini a gmail.com
Lun 19 Gen 2015 13:30:02 UTC
Più probabile che la RAM/qualche altro componente sia "guasto", ma non
abbastanza da non funzionare.
Interessante il fatto che il sistema non riesca a sistemare il
filesystem corrotto.

Io partirei con un memtest, almeno.
Se mi fai avere uno dei dischi, possiamo dargli un occhio.

Buffo però che il kernel non lamenti nulla e non intervenga.


Ciao,
Gelma


Il 19 gennaio 2015 12:59, Rimon Soliman <rimon.soliman a gmail.com> ha scritto:
> Ciao a tutti,
> vi scrivo per sottoporvi una questione che mi sta creando non pochi problemi.
>
> Ho un sistema basato su Debian che passa la sua vita a non fare altro
> che leggere i dati che gli arrivano attraverso la rete (attraverso un
> demone in ascolto su socket) e a fare INSERT e UPDATE di una specifica
> tabella di un database mysql. Questo avviene con una frequenza che
> arriva ad una volta al secondo 24h su 24.
>
> Dopo 15-20 giorni di attività, a volte un mese, il disco si corrompe e
> l'accesso ai file dati di mysql diventa impossibile. Di fatto sembra
> corrotto solo in quel punto perchè il resto del SO funziona
> correttamente e, ricreando la cartella mysql da un'altra parte il
> sistema riprende a funzionare. Un check del disco mostra errori di
> inode e non si riesce a cancellare e rifare la tabella delle
> partizioni o semplicemente a formattare la partizione esistente.
>
> Ho utilizzato 3 dischi SSD e uno HDD ottenendo sempre lo stesso
> tragico risultato. Sembra quasi che, scusate la mancanza di
> raffinatezza, il disco si rompa perchè si insiste troppo in un punto
> specifico scrivendo sempre sullo stesso file.
>
> Può davvero essere questa la causa? Esiste un modo intelligente di
> gestire una scrittura frequente dello stesso file attraverso una cache
> o qualcosa di simile?
>
> Intanto ho girato intorno al problema con uno script che ferma mysql
> rinomina la cartella dati con un nome di backup tipo mysql_2014_01_19
> e poi la copia per intero di nuovo in mysql e fa ripartire il
> servizio, costringendo così il disco a scriverla da "un'altra parte".
> Eseguendolo settimanalmente funziona, ma è una soluzione che speravo
> di evitare, mi sembra estremamente sporca.
>
> Grazie a tutti
>
> --
> Rimon Soliman
>
> --
> Info/Lamentele/Segnalazioni: andrea.gelmini a gmail.com
>



Maggiori informazioni sulla lista Lug