[06:27] Jutro [06:27] Kaj si strgal vjetre ? [06:29] BotaniCar: security breach u Hetzneru... [06:29] Pa, ocito nije u cijelom sustavu jer me nisu obavijestili o nicem [06:29] imas li dedicated ? [06:29] da [06:30] hmm... onda ti jos nije stigao mail :) [06:30] da, vidio i ja mail [06:30] a cak i nisam tamo [06:30] :) [06:31] http://jebo.me/pas/9 [06:35] jok, nista ni slicno nisam dobio [06:36] Uz to, "at the end of last week" .. cekali su 7 dana da posalju mail .. [06:50] jelly: SLO wiki je zakon :) [07:11] https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-prn1/933978_4853416384723_1692385198_n.jpg [07:59] MmikeT: jes tu? [07:59] tu [07:59] bas ubijo query cache na 2 stroja, a na 2 ostavio upaljena, testa radi :) [07:59] jel vi koristite xtradb na mysql bazama? [07:59] pa sam te se sjetio [07:59] vrodic: jest, svukud [07:59] :) [07:59] ok [08:00] doduse, koristimo perconu [08:00] koja to ima 'ugradjeno' [08:00] ma bas citam o group commitu [08:00] no nije da mi je to neophodno ako nemam bin_log ukljucen [08:00] u xtradb su to stavili iz mariadb-a [08:01] a, ovisi [08:01] to je uvijek bed, jer, moze se desiti da ti stvar prdne taman prije nego sto se commit desio [08:01] tj, prije nego sto je stvar zapisana na disk [08:01] s druge strane, mi sync_binlog uvijek imamo ugasen [08:01] jer, kad to upalis, onda stvari postaju neupotrebljive [08:02] ma group commit je optimizacija koja je i dalje acid, samo na standard mysqlu ne radi bas brzo ako se koristi bin_log [08:02] tj log_bin :) [08:02] pa, nije bas durable [08:02] http://kristiannielsen.livejournal.com/12254.html [08:02] ti je slican drek k'o syncrhoneous_commit u postgresu [08:02] ovaj lik je napravio brzi group commit za mariadb koji je kasnije prebacen u xtradb [08:03] od percone [08:03] log_bin se koristi kad god koristis replikaciju, right? [08:09] aha, kuzim (citam taj mysql bug) mozda uz xtradb/ovaj group commit od kristiana i sync_binlog=1 bude upotrebljiviji? [08:09] tj, to je poanta tog patcha [08:31] dvojim [08:32] jer, ovaj radi fsync nakon svakog pisanja u binlog [08:32] pa onda ako pises jos po innodbu [08:32] imas jedan fsync za redo log, pa za doublewrite log, pa za xa drek, pa onda jos jedan za binlog [08:32] ako ti treba pouzdana i brza transakcijska baza, odes na postgres [08:32] mysql just dosen't cut it [08:33] s mysqlom koristis sync_binlog=0 (i tako je default) i innodb_trx_commit_drek = 0/2 [08:33] i onda stvari lete [08:33] jos na slaveovima iugasis innodb_xa_stuff, pogotovo ako su read only [08:33] jer inace ne mogu pratiti mastera :) [08:36] lete, ali zaboravi acid? [08:39] Mmike: ovaj link koji sam ti poslao govori da je mariadb ekipa to rjesila [08:39] da nema jedan fsync po svakom insertu, nego da se grupiraju [08:39] i da to radi sa binlogom i sync_binlog [08:40] i da onda je acid [08:40] ne bi se cudo da nije puno sporiji od sync_binlog=0 [08:51] da, al' kuzis [08:51] ako ja imam 10 insertova/transakcija [08:51] koji se grupiraju [08:51] znaci da nakon prvog inserta i mog commita se u biti ne desi nista [08:51] i ako mi tad umre stroj [08:52] ostao sam bez te transakcije [08:52] ili krivo citam/kuzim? [08:54] dan [08:54] ali nitko ti ne garantira da su stvari commitane, osim ako si u transakciji [08:54] dakle i dalje si durable i consistent [08:55] ako radis commit na transkciju, onda se radi fsync [08:55] group commit to ne mijenja [08:55] ne kuzim [08:56] kad kazem: INSERT INTO bla (a) VALUES (1); [08:56] to je transakcija [08:56] ako pisem po innodbu [08:56] bez obzira sto nisam rekao BEGIN; i END; oko toga [08:56] correct? [08:57] samo ako je autocommit ukljucen u tom sessionu, zar ne? [08:58] tak normalne baze rade [08:58] pa, ne [08:58] jedan insert = jedna transakcija [08:59] ti u svom sessionu rondas ovo ono, i niko drugi to ne vidi [08:59] ok, imas pravo [08:59] ako nije autocommit ukljucen onda 10 insertova se komita tek kad zatvoris konekciju [08:59] huh? [08:59] a, svaki zapis u innodb tablicu mora biti transakcija [08:59] mislis, kad okines commit na kraju? [08:59] ne ide drugacije [08:59] sec [09:00] * Mmike rereads [09:00] Mmike: group commit grupira vise istovremenih transakcija [09:00] taj mysql je toliko usran i toliko krivo radi da onda ima svoju terminologiju kako to u biti treba [09:00] sto su to "istovremene" txje [09:00] hrvojem: da, al' i dalje te transakcije moraju biti serijalizirane [09:00] i jedna mora maaaaaaalcice cekat na drugu [09:00] it to radi ok [09:00] groupcommit pazi na redosljed izvrsavanja [09:00] ne radi ok u praksi, imas slim chance da ce ti se transakcija sjebnit [09:01] samo sto ti mysql to nece rec, tj, u docsima to nigdje ne pise [09:01] Mmike: ako rondaju po neovisnim podacima, teoretski ne moraju biti serijalizirane i moze se raditi reordering [09:01] jelly: istovremene concurrent [09:01] Mmike: prijavi bug, to bi bio prvi za group commit :) [09:01] jelly: teoretski :) [09:02] jelly: al' imas samo jedan transaction log [09:02] tj, innodb redo log [09:02] u koji se stvari zapisuju sekvencijalno [09:02] 'u koji' ili 'u kojeg' ? [09:02] Mmike: procitaj http://kristiannielsen.livejournal.com/12254.html sva tri posta, zbilja je ok i detaljno objasnjeno [09:02] Mmike: i tu valjda group commit moze zapisati N neovisnih txna odjednom [09:03] jelly: da, al' uvijek je jedan prvi a jedan zadnji [09:03] jedna, to jest [09:03] nebitno [09:03] jer su neovisne [09:03] bitno [09:03] jer kod group commita jedna moze cekati na group commit [09:03] pa nek ceka [09:03] pa da, al' za to vrijeme je klijent dobio 'commit ok' [09:04] ili ako imas autocommit [09:04] Mmike: nije [09:04] insert/update je prosao [09:04] ah, testiraj :) [09:04] pa vidi da je :) [09:04] to se u postgresu zove 'synchroneous_commit' [09:04] ak dobije commit ok prije nego je commit prosao (grupiran ili ne), cijela stvar nema smisla [09:04] grupiranje transakcija tako da se manje fsynca [09:05] yup [09:05] tj, ima smisla [09:05] jedino logicno je da baza ne daje commit ok nikome ko je u grupi [09:05] ako ti podaci nisu jaaaaako bitni [09:05] e jebiga sad [09:05] ali ne radi tako, Mmike ne dobijes ok prije pravog commita [09:05] tj, ako si koristio myisam prije, onda ti podaci i tako nisu bitni [09:05] hrvojem: eh, onda krivo kuzim. cek, citam iznova. [09:06] Mmike: onda ne govorimo o acid bazi nego igracki za djecu [09:06] Mmike: group commit radi samo za XtraDB i InnoDB ne i za MyISAM [09:06] tako je [09:06] i onda kad sa myisama predjes na innodb, svi pizde jer je sporo [09:06] i onda upale trx_commit = 2 [09:06] sto je i dalje pun kufer bolje nego myisam [09:07] Mmike: mislim zbilja procitaj 3 posta, lik je sve dobro/detaljno objasnio [09:07] tako da je i group commit pun kufer bolje nego mysam [09:07] jer s myisamom trpas podatke - nekud :) [09:07] k'o mongodb :) [09:07] hrvojem: eto, citam [09:09] Mmike: gle u perconi je to ukljuceno po defaultu od 5.5.18 i nije bilo niti jednog buga (ne znaci da ih nema) [09:09] a tu smo daklem [09:09] zato mi imamo toliko sranja od 5.5.18 [09:09] :D [09:09] serem, naravno [09:09] :P [09:10] hrvojem: ja sam to testirao davno, i to nije ok radilo [09:10] tj, je sa sync_binlog upaljenim [09:10] jer onda mysql koristi binlog da rekonstruira podatke u slucaju sranja [09:10] al' sa sync_binlog stvar radi toliko sporo da me sram [09:10] nije radilo = smrdao podatke, ili nije radilo = radilo jako sporo [09:10] cak i ako binlog metnem na poseban disk [09:10] nije radilo = nema durabilityja [09:10] imam 10 klijenata na 10 servera koji rokaju podatke [09:11] onda iztekam server iz struje [09:11] i kad se upalim gledam kaj je zapisano [09:11] zadnjih gro transakcija ne postoji [09:11] isti kurac k'o s postgresovim sync_commitom [09:11] ako imas veliki workload i jako puno pisanja, ostat ces bez dijela podataka ako to upalis [09:11] ako ne zelis da ti se to desi, ugasi sync_commit [09:11] binlog nema durability ili baza? [09:11] ili u mysqlu upali sync_binlog [09:12] btw, - zar je MariaDB transactional? Nije li to samo improved MyISAM? [09:12] ne mariaDB nije storage engine [09:13] mariaDB koristi XtraDB po defaultu, ali ima storage engine Aria (sto je malo boji MyISAM) [09:13] pretpostavljam da mislis na to [09:13] aha [09:13] al' je Aria i dalje non-transactional? [09:14] mislim da da, nisam to testirao [09:14] mislim da ako ti tak sta treba mozda bolje koristiti cassandru (MariaDB ima to kao storage engine) ili tokuDB [09:15] The idea is that when the system comes back up after a crash, crash recovery will go through the binary log. Any prepared (but not committed) transactions that are found in the binary log will be committed in the storage engine(s). Other prepared transactions will be rolled back. The result is guaranteed consistency between the engines and the binary log. [09:15] vish, mozda je tu bio bed (ili bud) [09:15] bug [09:15] da sam ja dobio 'ok' na prepariranu transakciju koja se rollbackala nakon crasha [09:16] Mmike: prijavi, po mogucnosti da se moze reporoducirat :) [09:16] mislim sigurno ce netko testirat i provjerit [09:17] hrvojem: tom ima bar 2 godine kako sam to probavao [09:17] isao sam mjerit dal' mysql moze biti brz kao postgres kod pisanja [09:17] i moze, kad pise u myisam :) [09:17] hm? groupcommit je tek godinu i pol star :) [09:17] hm, neznam [09:17] moram iskopati te testove negdje [09:18] ugl, znam da nije radilo dok nisam rekao sync_binlog [09:18] a lik u ovom tekstu pise da je to blio potrgano [09:18] tak da, u biti, pitaj boga sto sam ja testirao :) [09:18] ugl, postgres je svaki put prezivio 'istekaj-me-iz-struje', dok mysql nije [09:18] cak i sa innodb_trx_commit=1 [09:19] s tim da nije bed u diskovima, testirano na istom stroju [09:22] hm, ili je sa sync_binlog [09:22] nemam pojma [09:22] pravo vrijeme za ponoviti test [09:22] ugl, postgres radi JEDAN fsync po transakciji, dok mysql radi 50 [09:22] (ok, ne 50 al' bar 3) [09:37] nda [09:37] cini se da sam ja krivo zabrijao [09:37] al to onda znaci da 'pull the plug' test bi morao raditi [09:37] doduse, gotovo sam siguran da to nisam na perconi testirao nego na plain mysqlu :) [09:37] stvari koje percona radi sa mysqlom su prejebeno nevjerojatne [09:37] od drek proizvoda su napraivli skroz upotrebljivu stvar [09:38] i to ne pricam samo zato da mi hrvojem plati cevape :) [09:42] idem u ured [09:42] cu from there [11:57] kiši kiša [12:04] ja fino gledo kak ide preko dubrave, pa tu prek hiltona i onda dalje u tvom generalnom smjeru :) [12:13] prosla preko dubrave [12:54] * weshmashian opet gleda kisu iznad dubrave [13:25] * BotaniCar gleda u kisu koja pada po kozjaku i razmislja o kisi koja ostane iznad kvarta [13:57] sunce [14:00] sunce kisa sunce kisa sunce, e pa dosta je vise [14:18] takje ! sutra vodim dete na kupanje, ima da bude sunce suncE sunCE suNCE sUNCE SUNCE SUNCEE SUNCEEE [14:19] zakaj izmedju pocetka ssh konekcije i 'daj password' prompta cekam 20 sec ? ( imam UseDNS off u ssh conf fajli ) [14:20] messages i secure logovi ne govore nikaj pametno [14:21] hrvojem: vidim dosta replication related bugfixeva u mysql.com 5.5.32. jel percona koristi taj codebase ili? [14:22] trebal sam prije pitati, prije bi se i sam sjetio - trebalo je staviti "GSSAPIAuthentication=no" [14:23] vrodic: ne zadnje sto je izaslo od percone je PS-5.5.31-30.3, ako se ne varam 5.5.32 je izasao prije dva dana [14:23] treba nam ipak malo vremena da portamo sve feature ;) [14:24] ok, ma pitanje je u biti bilo dal percona tu ima neku drugu pricu, kad se radi o replikaciji, jer ovi bugovi mi i dalje izgledaju dosta ozbiljno [14:24] svaki minor release ima dosta scary-looking replication fixeva :) [14:24] tako mi se bar cini [14:25] heh da, ima nesta bugova koji su popravljeni u odnosu na mysql, ali ne znam zbilja napamet [14:26] uglavnom cini mi se da cu replikaciju pocet trosit tek kad vidim par minor release-a bez velikih fixeva :) [14:53] kisa Kanada [15:01] di sta ko [15:16] f1 :) [15:19] ah, trening === Vlado9A3CY_ is now known as Vlado9A3CY [17:27] BotaniCar: to mora da je centos, na debianu ne bi imao kerberos support instaliran po defaultu pa ti gasenje gssapi ne bi ne trebalo? [20:44] s cim citate pdf-ove ? :) [20:44] evince/nestodrugoopensource ili acroread ? [20:45] ja se nekak naucio na evince zadnjih godina, no "listanje" casopisa mi nekak sporo, reko zbog slicica/cegavec, sad probao listati iste casopise na najjeftinijem tabletu, tamo leti sunce mu [20:46] ocito zivim u zabludi vec neko vrijeme [20:46] prije sam koristio xpdf, ne znam zasto njega vise ne... [20:47] zanimljivo, xpdf mi se segfaulta...lijepo :P [20:48] jutro obruT [20:48] monolog? :) [20:49] ocito :) [20:50] svadjam se sa softverom i samim sobom :) [20:55] obruT: mupdf ? [20:59] dodobas: thanx, bacit cu pogled... za taj nisam ni cuo :) [20:59] bome, brz je definitivno, thanx [20:59] epdf mi uopce nist ne prikazuje :) [21:00] zanimljivo je to, puno readera, neki se segfaultaju, jedni nist ne prikazuju, jedni su spori, jedni su kde (to je bug :) ) bazirani... [21:00] i eto, mupdf cak i radi :)