Newsgroup: it.comp.os.linux.sys
Titolo: Re: Cosa puo' andare male?


aspettatelo domani sul tard�, oggi � ancora gioved�
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 Ed UN databse server.
a me pare sbilanciato come sistema.
un database server vuol dire che se ti salta la macchina sei hai 10 server 
fermi. 4 + 4 + 2
io metterei due master e uno slave.
ah, e poi c'è il backup da considerare
-- 
give it away

 (no, non rispondetemi: e' una domanda retorica)
Secondo me salter� uno dei CMS.

 (no, non rispondetemi: e' una domanda retorica)
Non rispondo.
Basta che tu ci dica quando pubblicherai la storia.

Gandalf Corvotempesta ha scritto:

Secondo il secondo corollario di rpoggi alla legge di murphy
sulla ridondanza, salter� l'unico elemento non ridondato, il
database server.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 (no, non rispondetemi: e' una domanda retorica)
Non vale se sai già la risposta :-)
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 database server.
Dimentichi l'unico switch su cui ha attestato tutto quanto.
Oppure l'unico firewall da cui escono.
Bud
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Oppure l'unico firewall da cui escono.
Non fanno parte degli elementi elencati da Davide nel post di apertura.


 Oppure l'unico firewall da cui escono.
secondo me nella sua storia si sono smarmellati i DUE load balancer
-- 
give it away

majale ha scritto:

dici che è tutto per la suspence?

 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)

 
Il database, che ovviamente è MySQL.
Ciao  Manlio

 Il database, che ovviamente ï¿œ MySQL.
Non credo...


sniff... sniff... sento puzza di casino

 sentirai il sex spingere da dietro ne riparliamo. :)

 Febbraio 2011
eh, ma sei bastardo forte però... :-)
S.

 Il database, che ovviamente è MySQL.
Auguri...

 apertura.
Appunto.
E' il secondo corollario di Ryo: si rompe ci� di cui non ricordavi
neppure l'esistenza.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 
Eh, 'un c'hai mica tutti i torti.


 Il database, che ovviamente � MySQL.
vuoi dirci che gli altri database avrebbero continuato a funzionare
anche con i dischi rotti, le ram bruciate e le CPU fumanti?
per quello che vuoi dire tu si usano i backup e non i sistemi di
failover: se brasi una tabella la braserai anche su tutte le repliche.
qualsiasi DB (compreso MySQL) una sistema di replica per il failover e
per il load balancing.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 Oppure l'unico firewall da cui escono.
e va be ... vediamo anche che fine hanno fatto le architetture
perfettamente bilanciate, ubicate un anno fa, tutte nella stessa sala
macchine, in un posto a caso dell'Italia: L'Aquila.


 anche con i dischi rotti, le ram bruciate e le CPU fumanti?
N� nel messaggio di Davide Bianchi n� in quello di Manlio Perillo leggo
alcun cenno, diretto o indiretto, a "dischi rotti", "ram bruciate" o a "CPU
fumanti". Come mai stai gi� sclerando tanto?

 anche con i dischi rotti, le ram bruciate e le CPU fumanti?
No, ma probabilmente sarebbero sopravvissuti a una semplice interruzione
di corrente. Ricominciamo?


Ma ti rendo conto che stiamo parlando di un DB che deve servire un 
ridicolo CMS?
Ma se fosse come dite voi, come farebbe facebook a gestire 1800 server 
mysql, con quantit� di dati considerevolmente pi� elevate?
La memcached che utilizzano non fa questo tipo di miracoli. Serve ad altro.



dici che se lo saranno posto questo problema per i 1800 (milleottocento) 
server MySQL di facebook?
no, metto le mani avanti: quello di facebook � MySQL puro con la 
memcached e niente altro aggiunto.
Ricominciamo?


 Ricominciamo?
MySQL in Facebook viene usato solo come "lippa ciucciadati", tutte le 
letture sono su memcached, tutte le scritture su cassandra.
Sempre per la cronaca:
1) Usano un MySQL 5.0.x patchato all'inverosimile: queste patch 
servono, fondamentalmente, a migliorare le performance di tutto 
l'ambaradan, evidentemente perch� come dici sono eccezionali (non lo 
usano per le read, non lo usano per le write, e *ancora � lento*, 
pazzesco). Oltre a questo, lo patchano per non fargli corrompere i suoi 
cavolo di log, proprio quelli usati per la replicazione.
2) Usano InnoDB, visto che hanno addirittura la pretesa di mantenere i 
loro dati.
3) E' ridondato all'inverosimile, del resto solo tu puoi rispondere 
vantando 1800 server ad una domanda sull'affidabilit�. Cosa pensi 
Adamo, che hanno i "dati grossi" o che non hanno abbastanza dischi in 
Facebook ? Ovviamente hanno 1800 server perch� ogni tanto si inchiodano 
/ corrompono, quindi ovviamente ridondano.
Giusto cos� eh, per un po' di chiarezza, che conosco il sistema "lo 
ripeto finch� non diventa vero" abbastanza bene, che me lo sono sorbito 
per un due annetti.
*Tutti* i dati di Facebook sono cachati, hanno hijackato il sistema di 
replica di MySQL: ogni volta che avviene una scrittura la chiave in 
memcached viene ripopolata. Questo ha funzionato all'inizio, le letture 
sono molto pi� frequenti delle scritture. Peccato che poi anche le 
scritture di MySQL si sono rivelate troppo lente sui 1800 
(milleottocento) server MySQL, e prima hanno dovuto metter mano al 
codice sorgente (rilasciando le patch sotto licenza BSD, chiss� se ti 
stanno ancora cos� simpatici quelli di Facebook), poi hanno dovuto 
implementarsi uno storage BigTable distribuito (Cassandra), usando 
MySQL solo e unicamente come storage di dati statico che ... replica 
memcached :D
Tutte queste informazioni sono facilmente trovabili in rete, il team di 
Facebook � molto aperto e vocale, basta solo cercare. Conosco anche 
degli ingegneri che ci lavorano, ma non penso sia il caso di andare a 
fare il fanboi di MySQL con loro, uno � anche piuttosto grosso e penso 
possa volare una bella sberla al "MySQL � sempre stato pensato per le 
performance" (o, pi� realisticamente, una fragorosa risata).
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US

 La memcached che utilizzano non fa questo tipo di miracoli. Serve ad altro.
Ma dove cacchio leggi di facce'nbocch, di memcached e di miracoli nei
post di Davide Bianchi e di Manlio Perillo?
Che ne sai che il problema sia stato hardware, software o umano, che ne
sai se � stato veramente (come pure � probabile) sul DB server, che ne
sai che quel DB server fosse veramente MySQL? E soprattutto chi ha
parlato mai di "dischi rotti", "ram bruciate" o "CPU fumanti"
pretendendo che un buon DB server funzioni anche in tali condizioni?

 performance" (o, più realisticamente, una fragorosa risata).
tanto per dare un'altra mazzata a mysql, andate a leggervi le thenical
news sul sito del Setiathome, hanno problemi con il db (mysql) un
giorno si e l'altro anche.
Ciao Jack

 "CPU fumanti".
Il messaggio di Davide sottolinea la presenza di _un solo_ server adibito a 
database. Ergo, se vuole dire qualcosa fra le righe, è sicuramente che si 
rompe/smette di funzionare per $CAUSA il server col DB. $CAUSA può essere 
software, hardware, inondazione, stormo di piccioni con la sciolta ecc.
-- 
Vide

 per un due annetti.
Per la cronaca: tra poco meno di 5 ore mi chiameranno da Palo Alto per 
un colloquio, per una posizione di feisbuccaro a Londra ^_^ Per la 
quale, dopo aver letto meglio il tipo di lavoro, risponder� picche: 
reliability engineer .... mo' si chiamano cos� quelli che guardano le 
lucette del monitoring :)


 lucette del monitoring :)
E che nesso ha con il topic?
Non hai un blog?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Non hai un blog?
Non ha nessun nesso, ma ha nessuna importanza stablire se un nesso 
esiste ^_^ Ci� che tu mi scrivi in risposta ha un nesso con il topic? 
Punta in qualche direzione? O devo intenderlo come un richiamo 
all'ordine? Potevi anche chiudere il messaggio, ed evitare di scrivere 
anche tu cose senza un nesso. Vedi cosa ne scaturisce adesso? Io 
rispondo nuovamente senza nesso al tuo messaggio senza nesso, e tu - non 
sapendoti trattenere - risponderai nuovamente senza una nesso e questa 
cosa finir�, si e no, tra una quindicina di giorni.
Stiamo sprecando davvero un sacco di bit in modo inutile. Bit che 
avremmo potuto utilizzare per ragioni ben pi� importanti, e con tanto di 
nesso, annesso e connesso!
p.s.: non ti interessa sapere come mi � andato il colloquio? ^_^
