Éjjel fél három...

...és megint elérhetetlen a hup.

Csak nem a MySQL csodás backupja fut? :)

( lajos22 | 2014. 09. 08., h – 02:54 )

Nálam csak a CSS hiányzik. Elérhető, írok is, ergo nem adatbázis. Hacsak a CSS nem MySQL-ben van...

Szerk: A linkedre visszatérve: https://www.dropbox.com/s/kcmejt8n0x3os0n/k%C3%A9p2.png?dl=0 Igen, teljes mértékben egyetértek ezzel...
(kezdek berágni erre a böngészőre mostmár)

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( manfreed (nem ellenőrzött) | 2014. 09. 08., h – 09:31 )

Ez a cikk nagyszerű. Az apropója pedig sajnálatos. Nagyon.
Update:
Arra azért kíváncsi vagyok, hogy melyik adatbázis / prog nyelv / akármi az, amiről nem lehet ilyen listát írni.

( Dacr (nem ellenőrzött) | 2014. 09. 09., k – 13:43 )

Pár éve már jeleztem Trey felé levélben, valami job fut ilyenkor a válaszuk alapján.

Szarul van megoldva a mentés. Amíg az adatbázis kisebb volt, megfelelt így. Most, hogy egyre nagyobb, át kéne gondolni, máshogy kéne megoldani.

Új vas is kéne lassan, frissebb OS-is. Frissebb AMP stack is. Frissebb portálmotor is.

Amíg az oldal új engine-je, a migrációs forgatókönyv és társai nincsenek készen, addig nem lehet/nem érdemes érdemben piszkálni. Amennyire én tudom, a munka folyik. Ezek körül már egyik sem az én feladatom.

Az is valami, hogy az oldal különösebb állás nélkül megy 13 éve. Jelenleg ez van. Éjjel meg inkább aludjatok.

--
trey @ gépház

"Szarul van megoldva a mentés."

Igen, a MySQL-ben leginkább. Értem én, hogy miért nem akarsz váltani, csak mondjuk ha valaki olyan szolgáltatást üzemeltet, ahol gond az, hogy megreccen az adatbázis, csak mert megy a mentés, ott azért nehéz azzal megindokolni, hogy "éjjel meg inkább aludjatok".

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha most az oldalt for-profit szempontból nézzük (és ugye az), és azt látjuk hogy az éjjeli röccenés ellenére bőven van látogató, akkor minek olyasmibe fektetni ami nem hozza be a befektetett energiát, pénzt? :)

--
arch,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Mitől sérülne az adat, ha a mentés nem lockolja a táblát? gyakorlatilag a mentés közben ha történik írás, vagy ráfut arra a sorra a mentés vagy nem. ha meg a mentés után változik a sor, az lock után is változna.
Bár nem tudom milyen módon fut a történet a hup esetén, nekem sikerült egy 1,5 milla + soros tábla mentését ezzel értelmesebbre csinálni. és ennek a javulásnak a miértjét a fentiekben leírtaknak megfelelően értelmeztem. Ami lehet faszság, merhogy nem vagyok diplomás (ergo hülye vagyok).

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

"nem csak bohóckodsz vele"
Értem Mr. Felsőbbrendű... Elfelejtettem, hogy csak bohóckodom...

Tegyük fel fél táblát updatelem miközben fut a mentés. Ok.
A mentés hogyan fut? soronként olvassa a táblát és menti. Pipa. (?)
Az update hogyan fut? soronként megy végig és módosítja az értékeket. Pipa. (?)
Ha a mentés valóban soronként fut, miért is baj, hogy a mentés aktuális sora előtt vagy után megváltozik az értéke? Ja mert a mentésben más lesz, mint az aktuális állapot? Akkor maradjon lockolva a tábla örökre, mert 2 mentés közt is változna...

Lehet, hogy nem jól tudom. Nem néztem konkrétan utána, mert sosem érdekelt. Megfigyelésemet írtam le. Azaz egész pontosan azt, hogy én úgy vettem észre, hogy így működik.
Nem jól tudom? Előfordulhat. Akkor le kell nézni a másikat, vagy meg is indokolod miért nem tudom jól?

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

"Ha a mentés valóban soronként fut, miért is baj, hogy a mentés aktuális sora előtt vagy után megváltozik az értéke? "

Az, hogy konzisztencia mond neked valamit? Vagy, hogy atomi művelet? Esetleg az, hogy tranzakció?

Ha kiadok egy update műveletet az egész táblára, akkor vagy legyen benne a mentésben teljesen vagy egyáltalán ne legyen benne. Félig ne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"atomi művelet"
Ez pont semmit mond. A másik kettő megvan.

"Ha kiadok egy update műveletet az egész táblára, akkor vagy legyen benne a mentésben teljesen vagy egyáltalán ne legyen benne. Félig ne."
Ok. Nekem nem volt igényem, hogy ne lehessen félig benne mentésbe a módosítás.

De akkor már bassza a csőröm, valóban így csinálja ahogy leírtam?

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Amikor én ezt használtam, akkor úgy volt megoldva a cuccos, hogy a MySQL csinált bin-logot is, mentéskor pedig a bin-logot újraindította. Az alapján már lehetett a mentés úgy csinálni, hogy félig lefutott módosítások is lehetett a mentésbe, mert visszaállításkor a binlogot is átzörgettem volna rajta. (sosem kellett használni amíg én felügyeltem. Azóta meg szétbaszták az egészet az "olcsóbb munkások")

Bár így visszagondolva. Az a helyzet, hogy akkor a mentés közben elő sem fordulhatott, hogy updatelnek valamit. Mert a mentés munkaidő után volt. Akkor meg csak valami script olvasgatott ezt-azt benne...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( Lacyc3 v | 2014. 09. 10., sze – 00:09 )

Sőt, valamikor fél éjfél fele szerintem valami cron is lefut, mert akkor is lassul szegény. A lényeg, hogy munkaidőben legyen gyors! :)