The other non-transactional storage engines in MySQL Server (such as MyISAM) follow a different paradigm for data integrity called “atomic operations.” In transactional terms, MyISAM tables effectively always operate in autocommit = 1 mode. Atomic operations often offer comparable integrity with higher performance.
(z dokumentace MySQL)
…tak nevím. :-)
"no treba kdyz mate oracle data guard nebo db2 hadr tak pri havarii neztratite ani jednu transakci a failover na backup server je za nekolik sekund. To je dost dobra vec pro online e=shop, nemyslite?"Myslím, že s výjimkou (ne)ztráty transakcí lze totéž realizovat s Firebirdem celkem jednoduše. Ztratím pouze nepotvrzené transakce, ovšem počítám-li s tím, že s touhle jedinou výjimkou si DB stroj může třeba totálně vyhořet, tak to snad není tak strašné. Jak ODG zachovává všechno? Spolupracuje s klientskou knihovnou na straně aplikace, aby kontext připojení přesměrovala na nový server? A kolik to vlastně stojí? :-)
Dalsi vec je mit db ktera je odzkousena a ne kterou dela par zoufalcu po vecerech.Ale já nepsal o MySQL. Já psal o databázi, kterou dvacet let vyvíjel člověk, od kterého Oracle kopíroval fíčury. :-)
Krom toho dneska se databaze daji zalohovat velmi rychle ty 2 TB co tu mame se zalohuji na pasky bez disk spoolingu neco malo pres hodinu. Takze jak tu mistni expert tvrdil 'databaze co muze mit i nekolik GB a to je pak problem' asi nikdy nevidel poradny HW.Brazilci cpou do Firebirdu deset tera (BTW, asi světový rekord v poměru velikost databáze/velikost serverového softwaru :-)) a prý si nestěžují. :] Českému e-shopu jistě pár tera pro data postačí s ohromnou rezervou.
db2 9.7 ma taky mvcc a nemusi delat ani stupidni vacuum (pg, firebird) ani pouzivat rollback segmenty (oracle). Nacita starsi verze radek z transakcniho logu. Oracle kopiruje kazdou zmenenou stranku do rollback segmentu, to generuje znacne mnozstvi IO operaci i kdyz ji nikdo nebude cist. DB2 se s tim zacne zabyvat az v pripade ze nekdo chce stary snapshot dat cist.No něco na upřesnění: Firebird většinu starých řádků odstraňuje průběžně na pozadí společně s běžným přístupem ke stránkám. Jakmile je zapotřebí provést "sweep", je to příznak, že se něco "podělalo". Pro starší verze řádku nemusí sahat do protokolu - nejenže transakční protokol nemá, ale proč sahat pro nejnovější verzi řádku do jedné (datové) stránky a pro dvě starší verze do dvou různých dalších stránek (protokolu), když je jednodušší a rychlejší všechno shrábnout z jediné diskové stránky? Opravdu "stupidní" řešení. :-)
Obvolaval jsem lidi at jim napisou ze chceme preportovat schema evolution z Z/OS do unix verze.Schema evolution? To jako tohle?
DB2 UDB for z/OS now provides the ability to change the definitions of tables and indexes without dropping and re-creating the object. This capability significantly enhances both the availability of your database and the performance of data access.Přidat sloupec do existující tabulky je "pokročílá fíčura"? Nejen že tohle Firebird umí, ale umí to už dvacet let, za plného chodu, je to transakčně opouzdřené a provádí se to lazy updatem dat (verzovaná metadata), takže se databáze nezasekne na půl hodiny, když přidám sloupec do desetigigabajtové tabulky.
- existuje k nim poměrně rozsáhlá dokumentace / nabídka školení apod. (což například pro Firebird neplatí, resp. neplatilo před cca rokem kdy jsem kloudnou dokumentaci hledal dost marně)
Dokumentace k Firebirdu spatna neni a behem par dni od objednani jsem ji mel doma na stoje, ale je placena.
Na linuxu s jeho demetni spravou pameti tam kdyz dojde pamet tak kernel odstreli ten oracle, pac ji ma nejvic
Tak hloupý zase OOM killer není. Nejdřív střílí procesy, které už dlouho nepožadovaly CPU čas. Krom toho mu lze celkem snadno říct (přes /proc/$PID/oom_adj), aby Oracle nechával až na později anebo vůbec nestřílel.
Tak s MyISAMem je problém i obyčejná úloha typu převod peněz z účtu na účet.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
Obecně pokud je pro zachování integrity dat nutné provést atomicky více než jeden příkaz, tak je to jen velice obtížně řešitelné.
1.
V prvni rade musite umet detekovat ze vam mysql samo od sebe zbuchlo nebo ze vam spadnul OS. Havarie OS ty dejme tomu budeme umet spolehlive detekovat, ale mysql je udelane tak ze kdyz crashne tak se samo restartne - jak vlastne zjistit ze padlo?.
Automatický restart zařizuje nějaký pomocný skript, který vůbec není nutné používat.
2.
Budete muset detekovat v aplikaci chybove stavy jako treba UPDATE vice nez 1 radky zarvalo protoze doslo misto na disku.
Aktuální verze se při zaplnění disku chová tak, že se daná operace zablokuje a čeká se, až se nějaké místo uvolní. Pokud vím, tak mimo uvolnění místa se z tohoto stavu lze dostat pouze násilným ukončením serverového vlákna, které tu operaci provádí, sama aplikace s tím nemůže už nic udělat.
3.
Takze detekce zda se vam vubec podelali nejaka data neni zrovna trivialni. Vetsina mysql aplikaci ignoruje nejake navratove kody, proste tam jen vali sql statementy.
4.
Fajn takze i kdyz sance ze zjistime potencionalni poskozeni dat je velmi mala rekneme ze to na 100% zvladame. Kdyz se to zjisti tak se musi zashutdownovat databaze co mozna nejdrive abychom zabranili dalsi ztrate dat - uzivatele vkladaji data do poskozene databaze. Ma na to vubec nami pripojena aplikace prava?
Tyhle dva body nechápu. K poškození dat může dojít pokud server spadne nebo ho násilně ukončíme, v obou případech už ale server neběží a aplikace se k poškozeným datům nedostanou.
5.
Pak je potreba udelat restore ze zalohy, vybrat spravne binarni logy od posledni zalohy a prehrat je. Zrejmne dost rucni prace admina.
Tak najít log s nejvyšším číslem a pustit ty tři nebo kolik příkazů zas tolik práce není. :-)