Názory k článku
Chyba v utilitě date rozbíjí automatické aktualizace Ubuntu 25.10

No ten clanek je tak trochu v duchu "jsem zvykli nejak to flikovat a cteni dokumentace povazuju za ztratu casu" :-)

Tohle je sice vtipný komentář, ale pokud v článku o nastavení výkonu MySQL serveru není ani slovo o tom, že to nelze dělat na živém serveru, tak je to jednak chyba v článku a taky se takový server prakticky nedá optimalizovat.

Zatímco u PostgreSQL si můžu dovolit nastavit co chci a přímo v konfigu je napsáno fsync a disable full_page_write, že je to nebezpečné. Ale server přes to pojede a o data nepřijdu a pokud mám replikaci, tak mám data na replice hned po potvrzení commitu.

Proto jsem hned po článcích o BTRFS napsal, jak to efektivně zálohovat a v každém dalším článku radím, že před každou akcí s daty se mají dělat snapshoty.

Pro mě je IT především o práci s daty. Pro autory MySQL a knih o nich asi ne.

Nesika vam rozbije cokoliv :-) Inu, ono spravovat postgre je jiny nez spravovat mysql, a kdyz kolem vas proleti nedejboze oracle, je to zase jiny. Kazdy engine ma sve specifika a nez se v tom zacnu hrabat, je dobre se s vlastnostmi toho konkretniho engine seznamit.

Btw dnes se vymlouvate na autory knih, zitra nastoupi vymluvy na AI? ;-)

Heheheh :-D

Tak já nevím, jaké máš nároky na nástroje ty, ale pokud DB ztratí data a ještě se u toho "směje", tak automaticky končí na blacklistu. A ono se to dostalo i do knih, recenzoval jsem jednu (Mistrovství MySQL nebo tak nějak), kde bylo napsané, že MySQL umí replikace, ale musíte to neustále kontrolovat (správnost dat na replikách). No, takže neumí.

Já jsem si poměrně brzy udělal na MySQL udělal názor, že je to něco, co radši nechci používat. Brzy jsem pak objevil PostgreSQL a tím pádem jsem i přestal mít potřebu MySQL používat – nedostal jsem se do těch několika málo specifických situací, kdy by dávalo smysl dát MySQL přednost. Takže jsem s ní přicházel do styku už jen v případech, kdy už někde byla a musel jsem tam něco dodělat. O to větší jsem si dával pozor (a obvykle se mi potvrdilo, že jsou stále dobré důvody se jí vyhýbat).

Vím, že se od té doby výrazně zlepšila, ale vlastně nemám důvod zkoumat to, jak na tom aktuálně je. Když hledám jiné databáze, než PostgreSQL, jsou to stejně NoSQL databáze. Proto ale píšu o MySQL v minulém čase, protože věřím, že současný stav už je podstatně lepší. Ostatně MyISAM, který byl zdrojem mnoha problémů, už dávno není výchozí.

Dobře, ale tam nebyl primární problém v tom, že by MySQL nějak sama od sebe ztrácela data (to neztrácí) ale v tom, že stačí sáhnout na konfig a už nenajede engine, který tam byl. A potom stačí import další DB a problém je na světě. Každý to máme jinak, ale já primárně očekávám hodně hlasité oznámení, pokud je něco nastaveno špatně. Ale hádky o systemd a autorestart tu opakovat nebudeme. ;-)

aneb řečeno, děláš zásahy na produkční databázi aniž bys dopředu si je vyzkoušel a věděl co přesně dělají a jak se chovají. Takhle dokážeš složit libovolnou databázi a je naprosto jedno, kterou si vybereš. Čím jí máš kritičtější, tím musíš přesně vědět, co se stane.

Mám se rád a vím, že málokdy se mi něco povede na první pokus bez chyby a čekám, že vždy se nějaké chyby objeví a musí se to odladit. Netroufám si ani dneska spouštět cokoliv, co nemám ověřené dopředu.

Jasně, ona každá věc je nějaký řetězec událostí a tady to muselo být optimalizované rychle, takže na testy nebyl čas. Já testy dělám vždy, ale pokud ti dá někdo termín do příštího týdne a potom to změní na "za hodinu" tak je to spíše jeho odpovědnost. A stále si myslím, že profi nástroj na to má upozornit. Vlastně mě nenapadá nic, co by se nechalo tak snadno zničit. (mdadm upozorní, lvm upozorní, postgresql to tam má napsané apod.) A já navíc mám tu příjemnou vlastnost, že jsem odstranil i server, o kterém jsem sice věděl, že nemá být vypnutý, ale tak když to někdo chce a naléhá na to, tak ho v tom rád nechám vykoupat :-) Příklad, že jsem na něco upozorňoval 14 let dopředu jsem už tady v nějaké diskusi uváděl.

Jak pravi klasicke rceni prace kvapna, malo platna :) Ja teda nevim, kdyz neohrabane sahnete do spfile u Oracle, nenabehne vam to taky - alter probehne, nikde to nenadava, po restartu mrtve. A to je "profi" databaze, nebo snad neni? I postgresql jde neohrabanym zasahem do konfigurace uvest do stavu, kdy to nenabehne. Nezlobte se, ale tady svadite svou vlastni neohrabanost a neznalost na nekoho jineho. Ale popisujete klasicky PEBKAC :)

PostgreSQL nenaběhne jako celek. A pokud někdo zruší omylem nějakou extension, tak zase neproběhne dotaz, typicky v transakci, takže se nic s daty nestane. Ale klidně se dál bav nad tím 15 let starým případem, v tom ti bránit nebudu :-)

A jestli to svádím na někoho jiného ... no každý má svou zodpovědnost. Pokud někdo někomu nedá dostatečný čas, tak je to skutečně pouze jeho problém.

To je ta knížka, která vyšla před 18 lety?

Kazdou technologii musite monitorovat a ne ji slepe verit :-) Skvele tu hejtite myisam, ale ono ten uz se moc nepouziva... on je dokonce oznacovan jako deprecated. Chapu, ze to v knizce z roku 2007 asi uplne nenajdete.. :D

Já tu knihu recenzoval pro LinuxExpres v roce 2010 (https://www.heronovo.cz/index.php/2010/05/28/recenze-knihy-mysql-profesionalne-optimalizace-pro-vysoky-vykon/). Trauma mám dodnes :-D

Ono je monitorovat a monitorovat. Jak chceš monitorovat dneska už desítky TB dat každou minutu? A pokud někdo řekne, že si to má hlídat ta appka, která to tam vkládá, tak potom opravdu můžu napsat vlastní storage engine.

Vy vycházíte z toho, že stále máme jen statement-based asynchronní replikaci a od té doby nedošlo k žádnému vývoji, ne? Chce to se posunout v čase dopředu.

Ono neni dobre byt otrokem minulosti a v IT to plati obzvlast, vzhledem k tomu jak rychle se veci vyviji ;-) Mozna si o tom prectete neco aktualnejsiho, nez dobovou literaturu z pocatku tisicileti...

Já rozhodně nejsem otrokem minulosti, proto jsem také na jaře psal, že postupně opouštím PostgreSQL a přecházím na MIN.io.

...coz je ale odlisny produkt s odlisnymi vlastnostmi :)

Tohle je spíše pokračování mého zájmu o pokročilé FS. Už před lety jsem o tom diskutoval jednak ve svých článcích a také na ABCLinuxu. Pro mě je BTRFS super FS se všemi vlastnostmi, ale vždy jsem to chtěl posunout na síť, tedy místo "přidej disk, pokud ti dochází místo" prostě přidat další storage server. Toto MIN.io umí "levou zadní".

Já takto používám i PostgreSQL, transakční ukládání dat se všemi metadaty, je to automaticky síťové a snadno se napíše server nebo rovnou klient, který podle hashe rozhazuje soubory třeba na 16 serverů (podle prvního písmena hash v hexa formátu). A pokud to nejde dát na síť, tak stačí mít 32 disků, 16x mirror a jednotlivé tablespaces na vlastním disku. Takto jsem to měl v menším i doma až na 256 tablespaces (pochopitelně o něco méně disků).

Já ti nechci kazit den, ale minio open-source už není - komunitní verzi už nikdo neudržuje a nevyvíjí.

Pokud chceš používat minio, tak si musíš zaplatit to jejich komerční řešení, jinak nemáš jistotu, že tam není nějaký bug, díky kterému třeba přijdeš o data, protože bugy už nikdo neřeší.

26. 10. 2025, 14:32 editováno autorem komentáře

Tak ono je to v goučku a celkem pěkně napsané (zrovna jsem si psal vlastní storage přímo v golangu, když jsem narazil na MIN.io), takže to jde opravit.

Opravit si to můžeš, pokud tomu rozumíš.

Moje pointa byla v tom, že bugy, které tam jsou v té open-source verzi, už nikdo opravovat nebude. Jejich open-source produkt prostě skončil.

Máte k tomu více informací, prosím? Také jsem chtěl minio začít používat a toho mne docela odrazuje. Díky moc.

To by mne také zajímalo, protože poslední update na githubu je starý dva týdny: https://github.com/minio/minio

Neco asi opravovat budou, ale odpoved k "nove" filosofii se da najit treba na...
https://github.com/minio/object-browser/pull/3509#issuecomment-2907951482
https://github.com/minio/minio/commit/9e49d5e7a648f00e26f2246f4dc28e6b07f8c84a#diff-185833cb26d7ac66a4d39042fd576a820c2c2c6d05ad18973bb9c7dce77267c5R14

No ale ani v jednom odkazu není nic o neopravování bugů. V tom prvním se baví jen o grafické konzoli (nepoužívám) a v tom druhém zase o tom, že nebudou dělat balíčky, protože stačí go install, což stačí. Takže zatím v pohodě.

No to sice explicitne neni, ale je otazkou nakolik se bude venovat pozornost komunitnimu projektu, kdyz pro ten komercni maji repozitare vitelne bokem (to tam pisou) a jsou neverejne - a soucasne v tom komunitnim delaji upravy, ktere vyhazuji funkce z komunitniho repa s tim, ze si mas koupit komercni verzi, kdyz to ci ono chces... s vymluvou na "bezpecnost" (jako u toho GUI) se da vyhodit postupne kdeco... jsou i dalsi indicie naznacujici mozne budouci problemy, jako treba ve fronte visici pull requesty, kteryma se nikdo moc nezabyva.

Tak jasně, mě to taky štve, takto skončilo mnoho nejdřív OSS projektů, ale tady jde o ukládání dat a to tam zůstane. Používají erasure coding, což je i v CEPH, takže všeobecně známá technologie a stovky milionů souborů do toho uložit lze, na síti se to distribuuje a vypadá to ok.

Jestli si teď hrají se svým novým AISTORE (ať už to znamená cokoliv), tak je to jejich věc.