[IMPORTANTE] Cosa è successo?

[Fabio Trebbi]

Questa è chiaramente una manifestazione fisica delle Leggi di Murphy

[Matteo Gallivanoni]

'cipicchia... mi dispiace davvero molto di quello che e` successo al forum e anche al server...

in effetti nei miei pochi anni di lavoro come sistemista
ho visto diversi problemi relativi a corruzione di
filesystem (su ufs di Sun principalmente, ma
qualcuno anche sotto ext2/ext3 - i molti sotto fat-e/o-ntfs
invece non li conto :-P),
ma nessuno cosi` strano come un fs con la cache *non in sync*
che va avanti per mesi senza comunicare alcun segnale
(al massimo mi  era capitato un crash seguito dalla comparsa
un link FISICO tra due directory, una contenuta nell'altra, da cui
con "du -smx ~"  risultava  che la home di un utente occupava
oltre 10 volte lo spazio totale  del disco /home ^__^ )

Per la prossima volta... come ci si puo' tutelare da questi problemi?
Con un "crawler" installato in locale che "dumpa" via rete tutto il forum e,
in parallelo,  un restore automatico dei backup
in un forum interno per la verifica della consistenza?
Magari e` una soluzione sporca e un po' "overkilling"... d'altra parte ora
sono solo il sistemista "di scorta" e il povero Renato mi deve
sopportare come utente :-P

[Rafu]

[cite]Autore: sigmud[/cite]Per la prossima volta... come ci si puo' tutelare da questi problemi?
Con un "crawler" installato in locale che "dumpa" via rete tutto il forum e,
in parallelo,  un restore automatico dei backup
in un forum interno per la verifica della consistenza?

Mi ricorda un po' la sorte del mio Protagonista in SHOCK:

[Massimiliano Lambertini]

come ci si puo' tutelare da questi problemi?

Sul versante  DATI:

http://dev.mysql.com/doc/refman/5.0/en/ha-overview.html

Su MySql non ne so molto: io lavoro con Oracle,  e quindi, a spanne suggerirei l'equivalente di un bel Stand By Database, ovvero un'istanza del DB che ospita una replica del DB di produzione in una macchina singola, replicato ad intervalli discreti. Ho visto che ci sono diverse soluzioni high-availability per mysql, al link indicato: varrebbe la pena darci un occhio.

E poi uno script che, periodicamente, fa un controllo sulla consistenza del DB (sul tipo un select del tempo dell'ultimo messaggio postato) e ti manda delle mail ogni volta che lo fa. Un nostro cliente ha una serie di DB da quasi un tera -- roba da baiocchi fitti -- e per tenere dietro alla macchina senza ogni volta loggarsi da remoto mando ad intervalli regolari una bella mail diagnostica -- diciamo che questo ti fa dormire abbastanza tranquillo.  

Ah, e cambiare file system. ^___^;

[Rev.Hyperclit]

Merdissima, tutte le hack di Hasimir e di altri, e i commenti, gli actual play, tutta la roba pre e dopo lucca... i whisper... i bookmark...

[Niccolò]

[cite]Autore: Lantheros[/cite]Ma non era SEMPRE colpa di Domon?

tu quoque!

[cite]Autore: sigmud[/cite]Per la prossima volta... come ci si puo' tutelare da questi problemi?

per una cosa simile l'unico modo che mi viene in mente è un backup in chiaro su due location diverse e uno "swap" ogni 24 ore tra backup e dati. magari gestioto via virtualizzazione?

[Renato Ramonda]

Il problema e' che il guasto era invisibile, ragazzi: i backup come scritto CI SONO, ma sono tutti inutili perche' venivano completati con successo... ma non avevano i dati nuovi dentro!

Certo, se fossero stati ripristinati su un secondo vanilla e verificati piu' o meno a occhio si sarebbe visto... il problema si sarebbe notato prima ma difficilmente risolto... ma sono procedure di disaster recovery che non ho visto usare nemmeno in grosse istituzioni

[Moreno Roncucci]

Ma se, da quanto ho capito, la macchina stava immagazzinando tutto quanto in RAM...  non stava rallentando in maniera strana? O erano files così piccoli da non fare differenza?

(più che altro vorrei capire se la cosa può ripetersi o se ci sono "segni premonitori" che adesso si possono vedere...)

[Renato Ramonda]

Per quello che ho capito io l'ipotesi piu' probabile e' quella di Khana su un controller impazzito: il problema e' ad un livello talmente profondo (quasi hardware, diciamo) che la macchina (il SO) non poteva accorgersene. Il controller dava OK alle scritture, che poi faceva chissa' dove.

...ma, appunto, nonzo: Michele ed il suo sistemista sono ancora in caccia.

[Massimiliano Lambertini]

[cite]Autore: renatoram[/cite][p]Il problema e' che il guasto era invisibile, ragazzi: i backup come scritto CI SONO, ma sono tutti inutili perche' venivano completati con successo... ma non avevano i dati nuovi dentro![/p][p]Certo, se fossero stati ripristinati su un secondo vanilla e verificati piu' o meno a occhio si sarebbe visto... il problema si sarebbe notato prima ma difficilmente risolto... ma sono procedure di disaster recovery che non ho visto usare nemmeno in grosse istituzioni [/p]

Cioè, in poche parole: GcG e non solo hanno girato sulla cache dei controller per oltre due mesi? Renato, su linux ne sai certamente molto più di me, però un qualcosa tipo questo:

http://dev.mysql.com/doc/refman/5.0/en/ha-drbd.html  

a 'sto punto è d'obbligo. Va bene che un controller si spacchi o impazzisca, ma due proprio no... (e poi: i backup di MySql sono solo fisici o esistono anche quelli logici?)

[Renato Ramonda]

Non e' nelle mie mani
Il ferro e' gentilmente offerto dal buon Michele, che ha gia' detto che e' in arrivo della ferraglia nuova.

[Davide Losito - ( Khana )]

Mah, secondo me è un evento molto poco prevedibile.
Di un controller raid ti -devi- fidare. Non puoi pensare che un giorno decida di disallineare la cache e iniziare a scrivere i dati della partizione primaria su superficie in teoria allocata per la partizione di mirror... perché secondo me è questo che è successo, e per la cronaca è il secondo caso che vedo.
Il primo era sul mio server web, capitato nel 2004 e costato all'azienda 4 giorni di hosting di emergenza, 2 giorni uomo di intervento di ripristino backup su suddetto hosting, + 2 giorni di rimborso servizi per down service provocato... il mio fegato ringraziò molto.
Non ho idea di come prevenire una cosa del genere, forse con un cluster in load balance... alla fine -questo- è uno dei motivi per cui ho smesso di fare il sistemista. Software is safeware.

L'altra alternativa plausibile è che sia impazzito TAR e abbia fatto delle copie in raw sovrascrivendo la partizione. Ma di questo dovrebbero esserci dei log da qualche parte...

[Alberto Rapalino]

Comunque, mi sbaglio o dai vostri commenti si evince che è un evento più unico che raro? Nel senso: si parlava di prevenzione ma c'è da sperare che una cosa così non ricapiti facilmente (almeno che non si tratti di una congiura, di un attentato degli Esoterroristi per diffondere il panico oppure di una concretizzazione davvero terrificante della Legge Murphy già citata da Fabio).

[Niccolò]

[cite]Autore: khana[/cite]Di un controller raid ti -devi- fidare. Non puoi pensare che un giorno decida di disallineare la cache e iniziare a scrivere i dati della partizione primaria su superficie in teoria allocata per la partizione di mirror... perché secondo me è questo che è successo, e per la cronaca è il secondo caso che vedo.

se è lo stesso problema (ad occhio mi sembrerebbe miracoloso che una persona veda una cosa del genere due volte...) significa che potrebbero esserci i dati su qualche altro disco dove NON dovrebbero esserci? tipo il disco di parità in raid 5?

[Davide Losito - ( Khana )]

La risposta breve è "sì", la risposta meno breve è "tanto con quei dati non ci fai nulla in ogni caso, perché parlare di disco di parità in raid 5 non ha più senso".
Ovvero i dati sono stati scritti ignorando l'allocazione dei chunk del raid 5... come se il disco fosse indipendente.
Ma stiamo ipotizzando, più propriamente "si è rotto tutto".