Fórum Root.cz
Hlavní témata => Server => Téma založeno: Pumlic 31. 01. 2017, 16:31:35
-
Cus, je vhodne pouzivat data=writeback na ext4 pro mysql?
-
Příjde na to, jak moc vadí ztráta dat, jestli je stroj na UPSce, jestli to má repliku atd. Možná lepší než writeback je HW raid s baterkou.
-
Řekl bych, že je to docela jedno, ale osobně u ext4, kde mi záleží na datech používám defaultní (a tudíž nejlíp otestované) ordered. Nebo to můžeš přesunout na XFS, které vlastně používá writeback samo od sebe.
Nic méně výkonnostní rozdíl na innodb nebude buď žádný, nebo bude i tak DB nepoužitelná. Disk, hlavně rotační, prostě nesmí být úzké hrdlo.
Pokud máš hodně zápisových transakcí a jsi ochotný jich pár v případě výpadku obětovat, tak si spíš pohraj s innodb_flush_log_at_trx_commit. Plus samozřejmě innodb_buffer_pool_size, innodb_max_dirty_pages_pct, innodb_io_capacity atd.
-
Příjde na to, jak moc vadí ztráta dat, jestli je stroj na UPSce, jestli to má repliku atd. Možná lepší než writeback je HW raid s baterkou.
Stroj je virtual u ceskeho poskytovale VPS, je to na SSD a predpokladam, ze to maji na UPS a server bude mit zrejme HW raid, jak moc nachylna je ta ztrata dat ? Nevim jesti jsem to presne pochypil, ale writeback dela to, ze metadata jsou zpracovana zurnalem, ale data samotna jsou zapsana az nekdy pozdeji (dle intevalu parametru commit ?), tedy pokud mezi zapisem metadat a skutecnych dat dojde k vypadku tak jsem data ztratil, protoze na disku je neco jineho nez by tam melo byt ? (data=ordered zapise metadata a hned na to data, tedy minimalizuje prodlevu).
-
...a predpokladam... bude mit zrejme ...
Tak nepredpokladej ...
Ale pokud ti je jedno ze o data prijdes ... tak muzes predpokladat i to, ze vazne maji i zalohy ...
-
maji na UPS
To sice ochrání před výpadkem proudu, ale ne před výpadkem HW.
server bude mit zrejme HW raid
To zaručuje, že všechny disky budou mít data k poslednímu flushi (commitu žurnálu), ale už nic poté.
Ale pokud ti je jedno ze o data prijdes ... tak muzes predpokladat i to, ze vazne maji i zalohy ...
Zálohy nejspíš mají, ale u levných VPS se typicky zálohuje jen jednou týdně. Navíc zálohy většinou vytahují, jen pokud se jim rozpadne pole, a zákazník nemá možnost si obnovu ze zálohy vyžádat.
jak moc nachylna je ta ztrata dat ? Nevim jesti jsem to presne pochypil, ale writeback dela to, ze metadata jsou zpracovana zurnalem, ale data samotna jsou zapsana az nekdy pozdeji (dle intevalu parametru commit ?), tedy pokud mezi zapisem metadat a skutecnych dat dojde k vypadku tak jsem data ztratil, protoze na disku je neco jineho nez by tam melo byt ? (data=ordered zapise metadata a hned na to data, tedy minimalizuje prodlevu).
Writeback a ordered žurnály fungují takto:
- do žurnálu se zapíše, jak se budou měnit metadata souboru
- nová metadata se zapíší na disk
- ordered: zapíší se všechna data na disk; writeback: začnou se zapisovat data na disk, ale zápis může pokračovat i po 4.
- změny metadat se v žurnálu commitnou
Oboje hrozí poškozenými soubory (pouze data=journal zaručuje konzistenci obsahu), ale každé jinak. U ordered je známo, jak velký byl soubor před změnou, při přehrání žurnálu se soubor zmenší na původní velikost, takže nemusí obsahovat všechna data a přepisy mohou být jen částečné, ale určitě neobsahuje bordel. U writeback to po commitu žurnálu už známo není, soubor tedy může obsahovat bloky, kam se ještě nestihlo zapsat a kde může být cokoliv.
A jak se s těmito situacemi MySQL vyrovná? MySQL po pádu přehrává log, kam si zaznamenává, co dělala; do logu se zapisuje vždy jen na konec, takže nehrozí problémy s částečnými přepisy. U ordered tak mohou chybět poslední příkazy, ty se prostě ztratí a neprovedou. U writeback ale na konci logu může být bordel a MySQL může udělat cokoliv, typicky odmítne log přehrát, databázi přepne do read-only a označí ji jako poškozenou.