[12:15] ovo je bilo fino! [12:22] ivoks, na sto tocno misils? :) === MmikeMRMA is now known as Mmike [12:23] karfiol [12:23] pojeo sam cijeli jedan karfiol za rucak :) [12:24] voda, malo soli, plin, vatra, malo vrhnja i papra i mmmmmmmmmmmm [12:24] a [12:24] jesi probao sirovi? [12:24] ne [12:24] probaj [12:24] odusevit ces se [12:24] zasto? zato smo izmislili vatru [12:25] zato sto je ukusnije? :) [12:25] da ne govorim zdravije [12:30] Daklem, porezna tvrdi da nisam placao akontacije poreza na dobit [12:30] i da sam im duzan oko 7k kuna [12:30] i donio sam im printscreen internet bankarstva, medjutim, to ne pali [12:31] i sad moram traziti banku da se ocituje oko toga, a to me kosta 500 kuna :) [12:31] go figure :) [12:36] pa to sam ja morao prosle godine [12:37] meni su rekli da sam imao vise prometa nego sto to izvod banke kaze [12:37] da bi se na kraju ispostavilo kako su mi dva puta u poreznoj racunali istu uplatu :) [12:38] ni izvod iz banke nije pomogao [12:38] morao sam sjesti sa zenom i crtati joj sve [12:39] opce ne kuzim [12:39] ja sam uplatio sveskup oko 8k kuna poreza na dobit, kroz akontacije [12:40] porezna tvrdi da je zaduzenje oko 5k [12:40] a da sam uplatio oko 1200 kuna [12:40] plus dug od prosle godine, pa je to cca 7k [12:41] mozda si uplatio na krivi pozivni broj [12:41] to se meni desilo [12:42] naime, imaju dva razlicita pozivna broja za akontakcije i zavrsni obracun [12:47] pa sve uplate mi idu na isto [12:47] znaci, ako sam sjebo, sjebo sam sve [12:47] odakle onda onih 1200 kuna koje sam kao uplatio? [12:47] nist mi to nije jasno ;/ [12:51] mozda od prije [12:51] ja sam nedavno skuzio da cijelo vrijeme uplacujem 2 mjeseca unaprijed :) [12:51] mozda si prosle godine preplatio na krivi pozivni broj :) [12:52] sjebano je to sve sa svim tim razlicitim pozivnim brojevima [12:52] men eto zivcira [13:04] pa, ima smila [13:04] al' da [13:05] jos ajde, porezna to ima relativno ok [13:05] ili tele2, jebeno su to imali - poziv na broj = id klijenta, odnosno mene [13:05] i onda sve uplate idu preko toga [13:05] a ne vipnet [13:05] stalno im se mijenja taj broj [13:05] cemu!? [13:19] ne kuzim ni ja [13:25] srecom je zena u poreznoj skroz razumna, zove me 'micek' :) [13:29] eto jos jedne stvari koju MySQL ima a PG nema (bar ne elegantno) [13:30] INSERT INTO baza1.tabica SELECT * FROM baza2.tablica ... [13:30] jel se ti to divis mysqlu? :) [13:34] :) ne :) [13:34] al' eto, ovo je skroz zgodno :) [13:44] Mmike, imam mysql pitanje za tebe :) [13:44] :) [13:44] sto postgres neki ne uleti :) [13:44] hajde [13:44] pitaj :) [13:45] Mmike, insertam 200000 rowova u tablicu; to radim u transakciji ne saom zato sto je to dobro inace, nego i zato sto zelim da mi svih 200000 budu vidljivi odjednom (iz raznih razloga zapravo radim delete svih, insert svih, jer mi je to lakse od ispitaj i updateaj jednog po jednog) [13:45] Aha! Znam di je (dio) zajeba s poreznom! Knjigovodja me uvjerio prosle godine da ne moram placati razliku, da cu to isplatiti kroz akontacije :) Opet, to je svega 1000 kuna... [13:45] e sad, myisam ima table level locking, sto znaci da mi readovi nece prolaziti sve dok se ovi rowovi ne insertaju [13:46] sto mi je tlaka [13:46] ja bi da readovi prolaze uredno (sa starim podacima) sve do commita [13:46] myisam - no can do [13:46] za innodb nisam siguran, al' mislim da innodb nije mvcc do verzije 5.5 (al' ovo sad lupam napamet) [13:46] e sad, mysql/myisam podrzava "concurrent insertove" u smislu da ako tablica nema rupu u sebi (tak pise u docs :), da ti concurrent insertovi funckioniraju [13:47] btw, brisanje 200k redova i onda vracanje nazad je, onak, dosta skupa operacija, siguran si da ne mozes to nekako mudrije napraviti? [13:47] nije moja baza ,myisam je u pitanju [13:47] brisanje 200k redova u mysqlu je trenutacno [13:47] try it :) [13:47] mysql interno napravi drop [13:47] da, na myisam tablici [13:47] pricam o myisamu [13:47] ne o innodbu, oracleu ili googleu [13:48] enivejz, druga opcija je provjeravanje svih tih 200k jel treba koji updateat [13:48] sto mi u praksi ztnaci select polja iz svih 200k redova [13:48] i nakon toga update nekog manjeg broja [13:48] nisam nit sam pametan sto napravit [13:48] hm, sad ja malo sirim pricu, al'... koji je uvijet selecta? [13:48] tj, uvijet provjere? [13:49] zasad jos nema uvjeta provjere, ali ako ga stavim, bit ce na uniqe keyani sha1sum podataka [13:49] jer nemam niti jednog drugog podatka (verzioniranje, itd) po kojem mogu provjeravati [13:49] hoce, ako radis jedan po jedan [13:49] al' sto je zajednicko tim podacima koje updateiras? [13:49] to da su drugaciji od podataka koji su vec u bazi [13:49] a nemam vrijeme promjene [13:49] nemam flag promjene [13:49] nemam verziju podataka [13:50] jedino sto imam je neki xml blob [13:50] kojeg importam u bazu [13:50] idealno bi bilo otkriti koji su promjenjeni [13:50] ali to mogu samo izravnom usporedbom svih polja [13:50] odnosno mogu napraviti hash digest pa usporediti samo to [13:50] sto je malo brze jel :) [13:51] da, al' opet ces updateirati redak po redak, sto zelimo izjbecio [13:51] necu updateati sve [13:51] recimo da selektam svih 200k [13:51] i vidim da ih moram 1k updateati [13:51] po cemu vidis da ih 1k moras updateirati? [13:51] onda mi je to jedan select svega [13:51] ok, probajmo ovako [13:51] banalan primjer, al' mozda me polovis [13:51] po tome sto napravim sha1sum svih i usporedjujem koji mi je razlicit iz baze [13:51] moram svih 200k xmlova parsati, taj dio je neizbjezan [13:52] ali dok to radim baza normalno radi, pa mi to nije problem [13:52] a xmlovi su ti u bazi? [13:52] ono sto mi je problem je dok ja pricam s bazom da ostatak svijeta mora biti s njom [13:52] ne, xmlovi su na disku [13:52] ono, import iz xmlova u bazu [13:52] nije neka filozofija :) [13:52] propustam neki dio :) [13:53] imam 200k xml fajlova [13:53] mosh dat neki konkretnan primjer, smanjeni scope jednostavnosti radi? [13:53] imam praznu bazu [13:53] imam svoj program koji proparsa svih 200k, i za svaki inserta jedan row u bazu [13:53] so far so good [13:53] drugi dan - neki od ovih fajlova su promjenjeni, ali ne znam koji (i ne mogu gledati vrijeme update, niti jet o zapisano u samom xmlu nazalost) [13:53] dakle, opet moram proc kroz svih 200k xmlova [13:54] i novopromjenjene staviti u bazzu [13:54] + one kojih vise nema u xml formatu maknuti iz baze [13:54] (ovog za micanje sam se sad tek sjetio da je isto req, ali to je faza 2...zasad gledam update dio) [13:54] dakle imam 2 izbora [13:54] prvo je brute force, obrisi sve, stavi sve nove, napravi to u transakciji tako da lijepo sve bude atomicno - problem s tim je ovaj concurrency r/w kod myisama [13:55] druga opcija je idi redak po redak (tj xml fajl po xml fajl), usporedi sa podacima istog tog retka u bazi (imam unique id integer key po kojima znam koji je koji), i ako treba updateati, updateaj [13:56] problem s tim je da nemam pametan nacin za usporedbu sto se promjenilo u fajlu osim da usporedjujem sadrzaj svih polja [13:56] pa [13:56] spominjao si hashiranje [13:56] pa to je mala optimizacija [13:56] pa i nije bas mala [13:56] pa jebote znam taj dio [13:57] ne pitam te to :) [13:57] pa to je way to go [13:57] ugl ako koristim hashiranje [13:57] onda moram selectati 200k hasheva iz baze [13:57] ovo prvo je pita zbog toga sto si rekao (mysam sranja) [13:57] ovo drugo je isto pita (200k updateova) [13:57] preformanse prvog i drugog su vrlo slicne, otkrit ces, prvo je nesto brze al' ima taj ruzan lock [13:57] ne moras [13:57] znaci [13:58] kak ne moram :) [13:58] imas XML dokument [13:58] napravis hash [13:58] uguras XML dokument u bazu [13:58] uguras hash [13:58] ok? [13:58] da, ofkors [13:58] sutradan se XML dokument promjeni [13:58] promjeni se i hash [13:59] nadjes samo one kojima se promijenio hash [13:59] kako? [13:59] hm, da, morat ces hasheve od svih dokumenata gurati u bazu svaki dan [13:59] al', dal' moze ovako: [13:59] kak bi ti to napravio bez da na ovaj ili onaj nacin moras izvuci svih 200k hasheva iz baze, ili, sto je jos debilnije, 200k selectova po 1 doc [14:00] napravis hasheve za 200k dokumenata koje imas na fsu [14:00] samo mi nemoj reci da napravim jedan sql select sa 200k uvjeta u where clauseu [14:00] gurnes ih u mysql (u tmp tablicu) [14:00] kazes mysqlu 'daj mi one kojima se hash promijenio) [14:01] hm [14:01] SELECT id FROM tmp JOIN orig ON tmp.id = orig.id WHERE tmp.hash != orig.hash [14:01] i dobijes IDjeve promijenjenih [14:01] i onda samo njih updateiras [14:01] mislis da bi guranje 200k hasheva u tmp tablicu pa to selektanje bilo brze od selecta samo 200k ? [14:01] napravis, dakako, i provjeru za one kojihi mas u mysqlu a nemas ih na disku i obrnuto [14:02] svejedno 200k hasheva ide preko zice [14:02] + za tu usporedbu zelim imati primary keyeve, sto je insert 200k rowova sa primary keyevima [14:02] primary key je jedan jedini, i to je ID dokumenta [14:02] pa 200k dokumenata po jedan primary key u temp tabilici [14:02] na hasneve ces vjerojatno postaviti indexe, iako, mala korist od toga jer moras svaki pregledati [14:03] pa brze bi mu bilo da provjerava 1po1 dal je gore i ako je da updejta ako je promjenjen i ako nije da inserta novi [14:03] drj_cro, nikako :) [14:03] pa nebi :) [14:03] overhead selectanja 1/po/1 je velik :) [14:03] znatan, rekao bih :) [14:03] a insertanje 200k redaka u tmp tablicu ide solidno brzo [14:03] + 200k updateova imi jednako loka bazu kao 200k selectova [14:03] err insertanja [14:04] ptlo, upravo tako, ako radis unutar jedne transakcije [14:04] al' [14:04] radim unutar jedne transakcije [14:04] ako se bilo gdje dogodi sranje [14:04] da. al si rekao da nemas toliko puno updejtova/insertova [14:04] zelim clean stanje [14:04] od tih 200k dokumenata, koliko ih se cesto mijenja? [14:04] btw, myisam i transakcije nisam bas siguran da rade kako mislis da rade [14:04] drj_cro, ali imam jednak broj selectova i to trajeeeee....svejedno ce lockat bazu [14:04] to provjeri svakako [14:04] Mmike, prilicno rijetko se mijenjaju [14:04] ja bi te dokumente spremao u git a ne u mysql [14:04] svakako bi bilo bolje updaati samo neke [14:04] ptlo, super! [14:04] ptlo, sam sec, telefon [14:05] jelly: a ja bi imao na racunu dovoljno para da ne moram radit pa onda ne bi morao ovo radit :) [14:05] eh sad [14:05] eh sad [14:05] jednako mi dodje :) [14:05] jos reci da ne smijes mijenjat shemu i dodati nesto korisno unutra [14:05] npr. ctime i mtime ;-) [14:05] smijem nesto malo, al nemrem bas stavit postgreqs umjesto mysqla ili mijenjati tip tablice itd [14:06] ctime i mtime su besmisleni [14:06] jerbo su ti xmlovi kopirani od negdje [14:06] i ctime i mtime ce svaki put bit drugaciji [14:06] problem je sto izvor dokumenata nema lijepi neki ctime [14:06] ili mtime [14:06] ili bar verziju [14:06] ali i ovaj hash ce posluziti [14:06] ja bi to slozio lokalno neki txt file sa hashovima pa hasho nove u txt2 i diffo razliku i te ubacio gore :) [14:07] drj_cro, pa jedna od opcija mi je da imam dbm fajl u kojem samo cacheiram hasheve [14:07] ali mi je traljavo imat 2 "baze" :) [14:08] a nekad si triper rjesenja cak i dobra :) [14:08] nda [14:08] ptlo, ako se rijetko miijenjaju onda ce ti razlika biti malo i updateova malo [14:08] samo, znaci, trebas skuziti koji su promijenjeni [14:08] da [14:08] da to mogu skuzt na brzi nacin, na konju sam [14:09] mislim nije nit da je ovo kak sad stoji sporo ... recimo 5min se izvodi [14:09] pa kroz hash tablice ti je najbrza stvar [14:09] ali mi je bed to sto bi mysql bio locked 5min, jel [14:09] mozes i ovako [14:09] hasheve ne cuvaj u mysqlu nego na disku [14:09] da, u lokalnom dbmu recimo [14:09] pa napravi nesto a-la `grep -v -f` [14:09] to sam isto mislio [14:10] nda [14:10] bed je, dakako, sto ti ne znas kad su ti dosli novi fileovi, right? [14:10] ti samo imas 'pristup' direktoriju di su fileovi i onda svako toliko gledas 'jel' ima tu kaj novo' ? [14:10] neam pojma, na svakom runu moram pretpostaviti da ne znam nista [14:10] basically ja im zip fajl kojeg skinem svako malo [14:10] raspakiram i onda gledam [14:11] neam pojma kad se mijenja pod kojim uvijetima se mijenja, itd [14:11] :) jeps, protokol nije bas najsretniji :) [14:11] ...dal se promjenio jednom ili vise puta od kad sam ja gledao .. [14:11] a well :) [14:11] znaci, od tih novih, napravis hasheve [14:11] nma nesto sa hashevima cu vjerojatno sloziti [14:11] i moras nekako usporediti nove i stare hasheve [14:11] sad, dal 'ces nove gurnuti u mysql pa onda vidjeti koji su promjenjeni [14:12] ili ces to napraviti van mysqla [14:12] jbg :) brijem da je mysql tu brzi od pythona :) [14:12] fora je da ti INSERT u tmp tablicu nece lockati mysql [14:13] isto tako SELECT koji trazi razlike isto ne locka mysql [14:13] samo UPDATE locka, al' velis da toga imas malo [14:13] brzina izvan mysqla mi nije kriticna jer se to u bgu negje izvodi [14:13] samo mi je bitno da dok petljam po bazi to ne affecta frontend dio [14:13] ok, bitno pitanje: [14:13] dal' si ti jedini koji mijenja podatke o xmlovima u mysqlu? [14:14] jesam [14:15] inace ovo sa dropom ne bi bilo dobro :) [14:16] super [14:16] onda napravi van mysqla 'skuzivanje' koji su se promijenili [14:17] grep -f je katastrofa spor btw, više se isplati generirati (...|...|...|...) regexp [14:18] to podrazumjeva da na nekom mjestu cuvas hasheve od podataka [14:18] jelly, grep je vise proof-of-concept, da, uzasno je spor ;) [14:18] kad si nasao listu razlicitih (kao i listu novih kao i listu onih koje vise nema) [14:19] zna netko dobru alternativu za lsyncd? [14:19] onda cak mozes te nove turnuti u tmp tablicu, i napraviti jedan UPDATE pomocu te tablice [14:20] jel slago tko mysql u active-active konfiguraciji ? [14:20] obruT: master-master? [14:20] obruT, jeps [14:20] obruT, extreme caution there [14:20] koje su zackoljice ? :) [14:20] ovi moji tu imaju neku ideju da bi to slozili pa ono, pitaju mene da se poigram s tim :) [14:20] ne radi (tm) [14:21] :) [14:21] :D [14:21] radi, al' traljavo [14:21] aplikacija mora toga biti svjesna [14:21] meni radi (tm) [14:21] vec godinama :) [14:21] sumnjam da je aplikacija svjesna iceg :) [14:22] ivoks, :) ti si disaster waiting to happen :) [14:22] ajmo opet od pocetka [14:22] zasto to ne bi radilo? [14:22] :) zato sto mysql nezna za 2pc [14:23] 2pc? [14:23] 2 phase commit [14:24] toga nema u ovoj aplikaciji :) [14:25] mysql samo replicira iz logova [14:26] u biti, ne vidim zasto bi 2pc bio problem [14:26] pa sto ako imas 2 updatea, razlicita, istog retka, na oba mastera? [14:26] koji ima prioritet? [14:27] oba se izvrse [14:27] jedan master napravi UPDATE A, i brije da je to - to. A onda mu replikacija posalje UPDATE B i podaci se promjene, a ovaj to ne zna. [14:27] tko ne zna? [14:27] Antonio Baladerekovic! :) [14:27] ok, imas tablicu: account_balance [14:27] ne smiju se oba istovremeno izvrsit :) [14:27] shvacam ja tebe [14:28] unutra imas: user_id, balance [14:28] i sad imas 1000, 500 [14:28] ali istovremeno nije ono sto ti mislis [14:28] istovremeno u svijetu racunala ne postoji :) [14:28] jedan mora napravit rowlock, drugi dobit gresku ako pokusa pisat u to vrijeme [14:28] tako je, ili cekat dok se lock ne oslobodi ic tek onda dalje [14:28] ACID is not just for tripping [14:29] * Mmike giggles :) [14:29] druga stvar je sto se zeli da kad jedan server padne, drugi i dalje radi... pa mene zanima sto se dogadja u tim slucajevima :) [14:29] sto bi se desilo? [14:29] joj, ivoks! [14:29] daklem [14:29] recimo jedan server padne, u drugom se naprave izmjene, drugi padne, a prvi podigne :) [14:29] aha [14:29] sorry, krivo :) [14:30] obruT, pa ne moze to tako :) [14:30] kak ne [14:30] moze [14:30] pa tak, fino, ne moze :) [14:30] sve je moguce u drzavi danskoj :) [14:30] jer nemas syncane podatke izmedju oba dva :) [14:30] obruT: /var/lib/mysql na shared storage [14:30] jer nemas nikakav locking :) [14:30] boze te isuse! [14:30] shared storage, a locking radi - tko? [14:31] govorimo o fail overu, ne? [14:31] jel govorimo? [14:31] obruT, ako ti treba failover, slozi master-slave replikaciju [14:31] i slozi nekvi hartbeat [14:31] svakako heartbeat :) [14:31] pa ako master prdne slave postaje master i nastavlja gdje je ovaj stao [14:31] mrtvi projekt :) [14:31] Mmike: ovima treba bas master-master [14:32] obruT, u koju svrhu? mislim, sto zele postici? [14:32] master-master je ok ako znas da, reicmo, parni upisi IDjeva idu na server A a neparni na server B [14:32] i onad se master-master replikuju medjusobno [14:32] al', app mora biti svjestan toga [14:32] i znati na koji server sto pise [14:32] komplikacija do bola [14:33] bice dva web servera sa par web aplikacija, na svakom po mysql baza, njih dvije bi trebale biti u master-master modu [14:33] zasto? [14:33] sto zelis postici sa master/master modom? [14:34] ocu postici to da stvar proradi kako je zamislila ova ekipa :) [14:34] pa kako je zamislila? :) [14:34] zele da ako jedan prdne da drugi nastavi raditi? ili zele da oba rade zajedno jer je jedan pre slab? ili sta? :) [14:35] bice navala pa trebaju oba radit da [14:35] ptlo: kak se zvao onaj filesystem od mongoa ili sto vec? [14:35] gridfs [14:36] dodobas: hvala [14:36] np [14:36] Mmike: kaze ekipa da bi jedan mysql bio zgazen ako bi oba servera isla na njega [14:36] obruT, vidi situaciju [14:36] imas jedan mysql [14:37] i imas 100 klijenata koji se kace gore [14:37] i primitivni primjer: update stanja racuna nekog klijenta, recimo [14:37] znaci, majstor hoce podici 1000 kuna sa svog racuna, a ima 1100 kuna na racunu [14:38] nisu takve aplikacije :) [14:38] pa unutar transakcije imas: SELECT saldo FROM balance WHERE id = kupac1; ; UPDATE balance SET saldo = saldo - 1000 WHERE id = kupac1; [14:38] i to je super [14:38] bam to je replicirano na drugi master [14:38] jedan korisnik ce pisat uglavnom po svojim podacima, a obzirom da ima sticky session ici ce uvijek preko istog servera [14:38] ajde, sad nastavi dalje... :) [14:38] ivoks, pustimo sad drugi master, ovo gore ne radi :) [14:38] jer [14:39] ako imas 2 konekcije koje pokusaju to isto, bez ikakvog lockinga, onda se desi da prvi i drugi izvrse select, dobiju da je saldo 1100, i onda oba izvrse UPDATE i na kraju imas da je saldo u minusu [14:39] znaci, treba ti nekakav lock [14:39] recimo: SELECT saldo FROM balance WHERE id = kupac1 FOR UPDATE [14:39] Mmike: znam ja to vrlo dobro, ali to ovdje uglavnom nece biti problem :) [14:39] slijedeci FOR UPDATE ce pokusati dobaviti update lock, nece uspijeti, i cekati ce [14:40] obruT: postavi se u realne okvire [14:40] vrlo je malo vjerojatno da ce isti podatak biti pisan u isto vrijeme [14:40] tek kad se prvi select dovrsio (a ako si sve stavio unutar BEGIN; END;) drugi select ce vratiti saldo 100, i jebise, nema u minus [14:40] Mmike ima pravo, u teoriji je svasta moguce [14:40] ali u praksi to bas i nije izvedivo [14:40] osim ako ovo ono [14:40] ali [14:40] ljudi [14:40] :) [14:40] znas sto imas, sto ce se raditi i eto [14:41] zato velim, aplikacija mora JAKO biti svjesna kako baza funkcionira [14:41] ok, znaci, ajmo rec da smo radili sa update lockovima [14:41] i sad to na jednom serveru radi super [14:41] sad stavis dva servera u master-master replikaciju [14:41] prvi SELECT FOR UPDATE ode na server1. Kako server2 zna da je server1 trazio update lock? [14:42] mene zanima kako ta replikacija interno radi i kako se rjesavaju problemi sinhronizacije nakon pada baza [14:43] pa, ako nisi svjestan ovog o cem pricam, onda to - ne radi :) [14:43] pa cita logove sa drugog mastera [14:43] Mmike: to sto ti pricas ja *vrlo dobro* znam [14:44] ima position na kojem je stao i onda cita sa drugog mastera od tog positiona dok ne dodje u sync [14:44] obruT, zato master-master ne koristis, osim u situacijama kad si siugran da ti to nije problem. Inace podatke baci pa-pa :) [14:44] sumnjam da ce vam bas trebati master-master [14:44] odnosno, kad ZNAS da ti se NIKAD nece desiti da radis UDPATEove nad istim retkom na dva razlicita servera [14:45] dakle, ajmo ispocetka [14:45] mene ekipa trazi da im pomognem slozit mysql server u master-master modu [14:45] mene se nist ne pita [14:46] ja bih to htio probat slozit i zanima me jel tko to radio i kako mu se to ponasa [14:46] ja sam to radio, ivoks je to radio [14:46] po razgovoru s njima i po aplikacijama za koje ce se koristit zakljucak je da je gotovo nevjerojatno da ce se po istom podatku pisat u isto vrijeme [14:46] sloziti takvo sto nije problem [14:47] http://www.howtoforge.com/mysql_master_master_replication [14:47] npr [14:47] problem je sto to nije bullet-proof rjesenje, a cesto ekipa koja radi 'gornji' sloj nije toga svjesna [14:47] mene je strah tako nesto slagat, uostalom ne ne volim mysql pa ono :) [14:48] gornji sloj su trivijalne web aplikacije - imas korisnika koji se ulogira, cita nekakve podatke, pise neke podatke, svaki korisnik pise svoje podatke, korisnik ima sticky session pa ce uvijek raditi preko istog servera [14:49] a jebote :) [14:49] ak su trivijalne, siguran sam da onda nema problema :) [14:50] najkompliciranija ce vjerojatno biti neki forum [14:50] nadji howto, slozi, kazi ljudima 'na', i nek testiraju [14:51] fakat nije komplikacija [14:51] komplikacije nastanu kad se aplikacija brije da su u bazi jedni podaci, a nisu [14:52] dodobas: jel to bolje od mogilefs? [14:54]