To, že různé varianty téže utility mají různé sady přepínačů, je běžné. Stejně jako se kvůli kompatibilitě dělá to, že se příkazy, které mají jiné varianty aplikace, ale daná implementace je nepodporuje, ignorují. Z hlavy mne napadá třeba MySQL, kde jste mohl zadávat příkazy pro vytváření omezení a indexů, jako podporovaly jiné databáze, ale buď to nedělalo nikdy nic, nebo to záviselo na použitém enginu, zda to byla noop operace, nebo to skutečně něco udělalo.
Chyba je v tomhle případě hlavně v tom, že se na to nepřišlo při testování.
Další důvod, proč nemít rád MySQL. Nevybavuju si jediný příkaz, který by ignoroval neznámý přepínač. Vše napíše buď error nebo rovnou usage help.
MySQL toho ignoruje tolik, že je to jediná DB, ve které jsme reálně přišli o data. Ignorace BEGIN a ROLLBACK na serveru, kde se instalátor rozhodl nenainstalovat InnoDB a MySQL ignorovala import ve kterém bylo create table engine innodb, takže to bylo myisam, které transakce neumí.
Chyba je v tomhle případě hlavně v tom, že se na to nepřišlo při testování.
Ano, nás skutečně nenapadlo otestovat to, že db server nevytvoří tabulku v engine, který jsme jí zadali. S takovou je skutečně lepší si napsat db sám. A to myslím vážně. Golang neodpustí nezpracování libovolné proměnné, takže každý err je potřeba zpracovat. Takže je lepší si data ukládat do souboru a poctivě po stránkách volat flush a data jsou bezpečně na disku a vím, co tam je. (Trochu sranda, ale MySQL mě skutečně nepřestává udivovat.)
Vzhledem k tomu, že parsování přepínačů není nijak standardizované a dříve byly vymyšleny různé hodně obskurní syntaxe přepínačů, dovedu si představit, že nějakou kombinací parametrů „obelstíte“ i program, který nevalidní přepínače hlásí jako chybu. Že zkrátka napíšete takovou kombinaci, že ten nevalidní přepínač bude považovat za hodnotu nebo poziční argument.
Třeba u mně příkaz echo v zsh neznámé přepínače chápe jako poziční argument a vypíše je.
Jenže ono nejvíce záleží na závažnosti případné ignorance. Databázi považuju v podstatě za strážce správnosti a uchování dat a ta nesmí ignorovat nic.
To, že Unix vyrostl na různých utilitách je jiná věc, ale třeba ve FreeBSD je vše napsané v sh a tam s ničím problém není a v core není ani nic ze světa gpl nebo linuxu, jejich core je prostě přesné a správné.
A bohužel i pro ten slavný systemd si raději píšu utilitky v golangu a spouštím to jako simple service, protože ani tam nelze v ExecStart použít vše a už jsem tam viděl hromadu bash onelinerů, kde se řešilo kde co. Tohle opravdu není cesta. Pokud vím, že můj program selže, tak chybu hledám pouze v jednom kódu. A ne v nějakém date apod.
Ok, tak to opravili těsně po naší katastrofě (můj původní článek z roku 2012: https://www.heronovo.cz/index.php/2012/01/26/report-ztrate-dat-aneb-proc-nemam-rad-mysql/).
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.
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.
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
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 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.