<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-03-22 23:20 GMT+00:00 Roberto Polli <span dir="ltr"><<a href="mailto:robipolli@gmail.com" target="_blank">robipolli@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> fare il fork per dumpare<br>
> il database... complicata da fare filare<br>
> liscia quando si fanno operations.<br>
Beh, dovendo fare una snapshot della RAM consistente, penserei:<br>
 - o fai lock;<br>
 - o fai cow;<br>
 - o ti tieni mvcc;<br>
 - o ti replichi su un'altro host e deleghi il dump a un nodo (eg MySQL).<br></blockquote><div><br></div><div>Ma si, essenzialmente si.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Implementarti mvcc costa di più che aggiungere i banchi...<br></blockquote><div><br></div><div>Dipende: tipicamente non e' quello che faccio io; ovvero non e' che mi riscrivo Redis. Se Redis mi da cazzi per via di sta cosa, prendo un prodotto diverso. E non sono assolutamente convinto che mi costi meno che aggiungere RAM. Anche perche', come dicevo:</div><div>1. il concetto di "aggiungere RAM" e' un po' obsoleto. quello che posso fare e' farmi dare una macchina piu' grossa.</div><div>2. non e' che me ne faccio dare una. o dieci...</div><div>3. c'e' da pagare il costo sostenuto di sta roba.</div><div><br></div><div>Quindi in pratica direi che mi costa meno cambiare tool. Ora, in effetti, semplicemente il problema lo ho bypassato rendendo redis completamente transiente; quindi semplicemente non fa dump non fa nulla e i dati che devono persistere finiscono altrove. </div><div><br></div><div>Che e' come dire che ho sostituito Redis (almeno per un certo use-case).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> per me i "se" diventano "quando" e i "puo'" diventano "quanti".<br>
Vista la tua esperienza, come risolvi di solito?<br></blockquote><div><br></div><div>Pianifico per il disastro. Cerco di fare in modo che i servizi possano sostenere diversi tipi di fallimenti e possibilmente recuperare (o almeno stabilizzarsi) per i fatti loro e poi ci si pensa il giorno dopo. Quando questo non e' possibile, faccio in modo che chi deve prenderli a calci abbia procedure ben definite per farlo.</div><div><br></div><div>Sono sempre le stesse cose... distribuire geograficamente, per dc. ridondanza a livello di host. eventualmente altri tipi di ridondanza. limitare il blast radius di un evento, etc etc etc. </div><div> </div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>