abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:33 | Zajímavý článek

Nejnovější publikace, jež rozšířila knižní řadu Edice CZ.NIC, nese název Unity – První seznámení s tvorbou počítačových her. Jejím autorem je pedagog a programátor Tomáš Holan, který pojal svou knihu jako průvodce pro ty, kteří by se chtěli s tímto nástrojem pro tvorbu 2D i 3D počítačových her seznámit, ale nevědí, odkud začít. Elektronická verze knihy je k dispozici volně ke stažení ve formátech PDF (2,7 MB), EPUB (7,9 MB) a MOBI (19,6 MB). Tištěné vydání si mohou zájemci koupit u většiny knihkupců.

Ladislav Hagara | Komentářů: 0
včera 18:33 | Bezpečnostní upozornění

Dětičky pod dozorem táty zkoušely hacknout tátův uzamčený počítač se Cinnamonem. Povedlo se jim to pouhým náhodným klikáním na virtuální klávesnici na obrazovce. Táta chybu nahlásil a je již opravena. Kliknutím na písmeno "ē" na virtuální klávesnici bylo možné shodit screensaver a tím obejít přihlašování.

Ladislav Hagara | Komentářů: 24
včera 10:00 | Nová verze

Byla vydána nová stabilní verze 1.10.0 distribučního frameworku Flatpak (Wikipedie), tj. technologie umožňující distribuovat aplikace v podobě jednoho instalačního souboru na různé linuxové distribuce a jejich různá vydání. Přehled novinek na GitHubu. Zdůrazněn je nový efektivnější formát repozitáře. Řešena je také bezpečnostní chyba CVE-2021-21261. Aktuálně lze z Flathubu, tj. centrálního repozitáře pro Flatpaky, nainstalovat 1 031 aplikací.

Ladislav Hagara | Komentářů: 1
16.1. 10:00 | Komunita

Společnost PINE64 stojící za telefonem PinePhone, notebooky Pinebook a Pinebook Pro, IP kamerou PineCube, hodinkami PineTime, páječkou (pájecím perem) Pinecil, zdroji PinePower nebo RISC-V vývojovou deskou PineCone publikovala na svém blogu lednový souhrn novinek. Opět společně s videem (YouTube, LBRY, TILvids). Od 18. ledna bude možné objednat PinePhone s předinstalovaným Mobianem aneb Debianem pro mobilní zařízení.

Ladislav Hagara | Komentářů: 26
16.1. 09:00 | Nová verze

Byla vydána nová verze 3.6 svobodného notačního programu MuseScore (Wikipedie). Představení novinek také na YouTube. Zdůrazněn je nový font Leland. Jeho představení na YouTube.

Ladislav Hagara | Komentářů: 0
15.1. 18:44 | Zajímavý projekt

Fedora Magazine představil projekt Fedora Kinoite aneb Fedoru Silverblue s prostředím KDE Plasma. Fedora Silverblue je neměnný systém s atomickými aktualizacemi, tj. základní systém je distribuován jako celek, s prostředím GNOME.

Ladislav Hagara | Komentářů: 4
15.1. 10:00 | IT novinky

Projekty Elasticsearch a Kibana, doposud distribuované pod licencí Apache 2.0, přejdou na duální licencování pod Server-Side Public License (původně používanou pro MongoDB a neschválenou jako open-source organizací OSI) a vlastní source-available licencí. Změna vejde v platnost počínaje vydáním 7.11.

Fluttershy, yay! | Komentářů: 0
15.1. 09:00 | Komunita

Na Humble Bundle lze do neděle 17. ledna do 19:00 získat zdarma počítačovou hru Bomber Crew (YouTube, Wikipedie) běžící také v Linuxu.

Ladislav Hagara | Komentářů: 1
15.1. 08:00 | Nová verze

Minimalistická linuxová distribuce Alpine byla vydána v nové stabilní řadě 3.13. Novinkou jsou např. oficiální obrazy v cloudu (AWS EC2), vylepšené síťové nástroje nebo podpora PHP 8.0.

Fluttershy, yay! | Komentářů: 0
15.1. 07:00 | Bezpečnostní upozornění

Uživatelé Admineru verze 3.7.1 a starších mohli být 29. a 30. prosince napadeni. Útočníkovi se podařilo do souboru jush.js, který se do této verze ještě stahoval z adminer.org, vložit kód, který mu odesílal přihlašovací údaje. Pokud jste v tomto čase tuto více než 7 let starou verzi Admineru používali, tak změňte hesla databází, ke kterým jste se přihlašovali. Novější verze ovlivněné nejsou.

Ladislav Hagara | Komentářů: 2
Jestliže používáte distribuci CentOS, kterou náhradu plánujete vzhledem k oznámenému ukončení vydávání?
 (30%)
 (3%)
 (2%)
 (23%)
 (0%)
 (2%)
 (41%)
Celkem 155 hlasů
 Komentářů: 3, poslední 10.1. 13:01
Rozcestník
Aktuální zápisy

Předumpování databáze, aneb bude to brnkačka

19.6.2020 08:03 | Přečteno: 1874× | Výběrový blog

Rád se podělím o jednu epizodu z práce adminstrátorské, protože obsahuje pár technických zvrat(k)ů a možná i obecné životní poučení :)

Začátek

Kolega se snažil zkopírovat jednu instanci databáze do druhé. Jenže se mu to pořád nedařilo. Řešili to na poradách už asi tři týdny a pořád žádný výsledek. Už od začátku jsem v hlavě tušil, že bych hravě zvládnul, ale sám toho mám hodně a vůbec, tenhle projekt není moje starost. Jenže to porady pořád natahovalo a už to začínal být opruz i pro mě. Tak jsem se do toho vložil a dobrovolně se nabídl, že vyřeším.

O co jde

Jedná se o jednu Percona 5.6, čistě InnoDB databázi, ve které začalo konstantně leakovat místo na disku:
Graf Projekt trochu znám a tušil jsem, že tam bude hodně databází a tabulek. Řešení za mě je komplet předumpování do nové čisté instance. Kolega zkoušel všelijak binárně a pomocí replikace bez výpadku, ale nikam se nedostal. A vůbec, dump je grunt, jak říkal můj dědeček administrátor. Navíc jsem se cítil silný v kramflecích, už jsem toto v menším měřítku párkrát dělal.

Prvotní zmapování

Kontrola konfigurace ukázala, že až na pár rychlostních optimalizací je DB nastavena správně (innodb_file_per_table!). Počet databází: 5 000, počet tabulek v nich: 550 000, největší tabulka ne více, než 500MB, naprostá většina mnohem méně. Výpis se dá získat takto:
SELECT
concat(table_schema, '.', table_name) tbl,
engine,
concat(round(table_rows/1000000,2),'M') rows,
concat(round(data_length/(1024*1024*1024),2),'G') DATA,
concat(round(index_length/(1024*1024*1024),2),'G') idx,
concat(round((data_length+index_length)/
(1024*1024*1024),2),'G') total_size,
round(index_length/data_length,2) idxfrac
FROM information_schema.TABLES
WHERE table_schema not in
('mysql', 'performance_schema', 'information_schema')
ORDER BY data_length+index_length DESC;
BTW toto SQL běželo půl hodiny.

Plán akce

Mysqldump po databázích ukazuje něco přes 8 hodin. Tudy cesta nevede, ale to jsem věděl už od začátku a měl připravené řešení: budu dumpovat po jednotlivých tabulkách parelelně a získám tím potřebnou rychlost. Projekt snese pár hodin výpadku mezi druhou až dejme tomu pátou ráno. Mým cílem ale bylo ne déle, než 2 hodiny. Mám na to už hotovou kostru skriptu, hlavní práci odvádí tato část:
while read -r db tabulka; do
	(( i++ ))
	echo "(${i} / ${tabulky_pocet}) ${db}.${tabulka}"

	while (( $(jobs -p | wc -l) >= $POCET_PARALELNICH )); do
		sleep 0.1
	done

	predumpuj "$db" "$tabulka" &
done <<< "$tabulky"
wait
echo "Done"
Mysqldump sype data rourou rovnou do nové DB.
Skript mám hotový relativně brzo, dodělal jsem do něj hlavně zobrazení ETA a průměrné rychlosti, přeci jen chci u takto velké DB vidět nějaký progress.

První test

Jde se na první spuštění, díky --skip-lock-tables pro mysqldump můžu i v produkční době, navíc server má výkonu dost. POCET_PARALELNICH nastavuji na 20, po zkoušce jestli server nespadl dávám 40 a vypadá ještě trochu rychlejší. Nyní dumpuje rychlostí cca 100 tabulek za vteřinu v průměru. Jsem nadšen a ruším limit na prvních 10 000 tabulek a chci nechat předumovat všech 550 000.

Dump běží krásně a už si plánuju budíka na druhou ráno, že rovnou překlopím. Jenže ...

Bash bug?

Průměrná rychlost postupně klesá a ETA se prodlužuje, ale to přisuzuji faktu, že narážím na tabulky, které jsou trochu větší. Jenže rychlost klesá pořád až se ETA blíží ke třem hodinám. To jsme na cca 50 000 tabulkách a rychlost je zhruba na polovině. Podezírám databáze, zkouším všechno možné ale děje se pořád. Až mě napadá: třeba to brzdí samotný bash? Chvíli exerimentuji s různými implementacemi paralelizace ve skriptu, ale posun žádný. Až google:
https://unix.stackexchange.com/questions/573315/bash-script-that-runs-parallel-threads-slows-down-substantially-over-several-hou
Tak je to přece jen bash! Naštěstí v odkazu výše jsou uvedené možné alternativy, jako první volím pro paralelizaci xargs.

Jiná paralelizace

Přepis do xargsu už je rychlovka, hlavní část vypadá takto:
echo "$tables" | awk '{ i++; printf("%s %s %s\n", i, $1, $2) }' | xargs -n 3 -P "$POCET_PARALELNICH" ./predumpuj-worker.bash
výstup workeru loguji takto přímo v něm:
flock /root/predumpuj_worker.log echo "${1}	${2}	${3}	${ret}" >> /root/predumpuj_worker.log
Díky tomuto logu a příkazu pv mám i jednoduchý progress i s ETA:
tail -n0 -f /root/predumpuj_worker.log | pv -l -s 550000 > /dev/null
Takto už šlape plnou rychlostí po celou dobu a plánuji ostré překlopení na druhou ráno. Čas celého dumpu: cca 70 minut. Skript je takto i mnohem kratší a elegantnější.

První ostrý pokus

Budík mě probudil, ale vstával bych stejně - dělal jsem něco i pro jiného zákazníka. Vše jde dobře a pouštím dump. ETA najednou 3.5 hodiny. WTF? Výkon na serveru je, disky stíhají (SSD), proč to najednou nejde?
Po hodině se nelepší, tak celou akci odvolávám.

Čím to je?

Celá akce už jde mnohem složitěji, než jsem čekal. Trochu se toho začínám bát, že bych to nakonec nezvládl? Co bylo na ostrý pokus jinak? Až mi to na procházce dochází: předchozí pokusy nanečisto jsem dělal do prázdné databáze, zatímco ráno jsem zapisoval do databáze už jednou dumpnuté. Další testy tezi potvrzují - přepis dat je mnohem pomalejší, než zápis na čisto.

Druhý ostrý pokus

Budík vzbudil, začátek dobrý :) Dump frčí krásně, ETA dokonce 65 minut. Za 63 minut předumpováno, dělá tedy průměrně 145 tabulek za vteřinu. Zajímavost: v každém běhu cca 100-200 tabulek selže dump. Díky logu dohledám a pustím jejich dump znovu. Nyní proběhnou. Asi tam v prvním průběhu nejsou nějaké potřebné závislosti v databázi.

Konec a poučení?

Akce tedy proběhla, zabrané místo na disku se opět vrátilo do normálu a už se neztrácí do neznáma. A poučení? Byl jsem si až příliš jistý, že se snadno podaří :) A možná taky, že i v bashi (čemkoli) může být bug. A nakonec - když nevíš, použij google, už to určitě někdo řešil! :)

Bonus na závěr

Tato publikace zvedla naše znalosti MySQL/Percona na novou úroveň:
Google: Speedemy-MySQL-Configuration-Tuning-Handbook.pdf
Určitě doporučuji.        

Hodnocení: 100 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

19.6.2020 09:11 debian+ | skóre: 23 | blog: analyzy
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Poznas prikaz parallel?
debian.plus@protonmail.com
19.6.2020 09:36 henk | skóre: 1 | blog: henkovi_prdy
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Vím, že existuje. Ale xargs znám už déle, tak dostal přednost. Navíc mi parallel nepřišel moc intuitivní, když jsem na něj koukal naposled.
19.6.2020 10:21 debian+ | skóre: 23 | blog: analyzy
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Ja preferujem na pararell nieco: v tom duchu (zas bez toho formatovanie vety v tom a s :::: som pouzival)
debian.plus@protonmail.com
19.6.2020 09:21 petr
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
A cim bylo zpusobene to leakovani mista na disku?
19.6.2020 09:39 henk | skóre: 1 | blog: henkovi_prdy
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Kolega na to nepřišel a já neměl čas se v tom vrtat. Jinak databáze je hodně stará a prošla mnoha verzemi(upgrady), tak mi přišlo lepší ji rovnou takto vyčistit.
Max avatar 19.6.2020 11:03 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Hmm, pěkný leakožrout :)
Zdar Max
Měl jsem sen ... :(
19.6.2020 11:24 johnyK | blog: uxblog
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
projekt, ktery ma 5000 databazi a celkem 550 000 tabulek? Tim se ridi zemekoule, vesmir nebo Agrofert? Uz u SAP jsem si rikal, ze kdyz to ma v zakladni sestave 60 000 tabulek, tak ze se panove analytici u SAP zblaznili, ale jak je videt ono se to da gradovat.

Ostatne soudim, ze fandove relacnich databazi a cele te teorie okolo by se meli nechat vysetrit :-)
19.6.2020 12:26 Faceless man
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Tabuliek v DB nieje nikdy dosť ! :-P
19.6.2020 12:29 ehmmm
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
A pritom to ma jen 100 GB. (?)
19.6.2020 12:41 Faceless man
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Na SQL db málo !
19.6.2020 14:13 henk | skóre: 1 | blog: henkovi_prdy
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
:) Řekl bych co to je, ale nejsem si vůbec jistý jestli můžu. Je to prasečina a kdyby se na to někdo podíval, tak by možná zjistil, že půlka jde promazat. Ale to teď nikomu nestojí za námahu.

Jinak k těm prasečinám: viděl jsem i systém, který pro ukládání dat používal názvy sloupců. Následně narazil na interní limit MySQL, tak jsme mu kvůli tomu museli upgradovat na verzi, která má limit výše :)
Josef Kufner avatar 19.6.2020 14:14 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Neemuluje se těmi tabulkami dělení dat do partitions?
Hello world ! Segmentation fault (core dumped)
19.6.2020 15:40 podlesh
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Myslím že je naprosto jasné že ty tabulky nivytvořil žádný analytik, ty jsou prostě generovány za běhu. Možná jsou to dočasné tabulky a chybí mazání?
Heron avatar 19.7.2020 20:43 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Viděl jsem projekt, který vytvářel DB per uživatele. Těch tabulek tam nebylo 110 per DB, ale trochu míň. Tuším snad SOGo nebo něco z balíku iRedMail. Je to prasárna, která nemá žádnou výhodu (možná až na jednoduchý drop v případě smazání uživatele). Navíc v žádném normálním DB produktu by to nešlo dělat, obvykle se připojuje ke konkrétní DB a nikoliv k serveru. Ale MySQL to má hold takto.

Ale proč to dělají takto fakt netuším. Když tam těch userů bude fakt hodně, tak v případě MySQL to znamená stejný počet adresářů. Tuším že u ext3 byl limit 32tis podadresářů v jednom adresáři. Tj jen 32tis uživatelů. Kdyby to bylo v normálně strukturované DB, tak by nebyl žádný problém několik milionů.
19.6.2020 15:53 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
innodb_file_per_table je na prd. docela často tomu nějaká tabulka uletí a pak se to musí nahánět, že se ztratil nějaký soubor, takže tabulka neexistuje, kromě případů, kdy ji chcete vytvořit, to pak hází chybu

innodb_file_per_table je ovšem taky na prd, to si ten innodb soubor pěkně bobtná a když pak v serverovně vypadne napájení (samozřejmě zálohované, asi zálohovaný výpadek), tak možná máte o celodenní zábavu ve formě obnovy databází ze záloh postaráno

Ale můžete si vybrat :-)
Quando omni flunkus moritati
19.6.2020 19:03 Odin1918 | skóre: 5 | blog: Valhalla
Rozbalit Rozbalit vše Re: Předumpování databáze, aneb bude to brnkačka
Predne je fajn, ze jste si nejak poradil. Co uz fajn neni, je fakt, ze se nikdo nezaobiral resenim priciny problemu. I kdyz chapu, ze toto vase reseni ma nejnizsi naklady na lidske zdroje. Do budoucna bych se zamyslel nad pouzitim nejake opravdove databaze. PostgreSQL urazil za posledni roky hezky kousek cesty a myslim si, ze na takove mnozstvi dbs a tabulek je to urcite lepsi alternativa. Pokud vam tam takove objemy vznikaji nejakou primitivni emulaci partitioningu, urcite bych ten postgres doporucil tim spise.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.