RYCHLÉ uvolnění databáze v klidovém stavu:
Použití volby "-T " s mysqldump má za následek mnoho souborů .sql a .txt v určeném adresáři. To je o ~50 % rychlejší pro ukládání velkých tabulek než jeden soubor .sql s příkazy INSERT (zabere to o 1/3 kratší čas nástěnných hodin).
Navíc při obnově existuje obrovská výhoda, pokud můžete načíst více tabulek paralelně a nasytit více jader. Na 8jádrovém boxu by to mohl být až 8násobný rozdíl v čase nástěnných hodin pro obnovení výpisu, navíc ke zlepšením účinnosti, které poskytuje „-T“. Protože "-T" způsobuje, že každá tabulka je uložena v samostatném souboru, je jejich paralelní načítání jednodušší než rozdělení velkého souboru .sql.
Vezmeme-li výše uvedené strategie do jejich logického extrému, bylo by možné vytvořit skript, který by široce paralelně ukládal databázi. No, to je přesně to, co Maakit mk-parallel-dump (viz http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) a nástroje mk-parallel-restore jsou; perl skripty, které provádějí více volání základního programu mysqldump. Když jsem je však zkusil použít, měl jsem potíže s dokončením obnovy bez duplicitních klíčových chyb, které se nevyskytovaly u vanilkových výpisů, takže mějte na paměti, že vaše kilometry se mohou lišit.
Dumpování dat z LIVE databáze (bez přerušení služby):
Přepínač --single-transaction je velmi užitečný pro vytvoření výpisu živé databáze, aniž byste ji museli uvést do klidového stavu, nebo pro vytvoření výpisu podřízené databáze, aniž byste museli přestat ukládat.
Bohužel -T není kompatibilní s --single-transaction, takže získáte pouze jednu.
Obvykle je odstranění skládky mnohem rychlejší než její obnova. Stále existuje prostor pro nástroj, který vezme příchozí monolitický soubor výpisu a rozdělí jej na několik částí, které se načítají paralelně. Pokud je mi známo, takový nástroj zatím neexistuje.
Přenos výpisu přes síť je obvykle výhra
Chcete-li naslouchat příchozímu výpisu paměti na jednom hostiteli, spusťte:
nc -l 7878 > mysql-dump.sql
Poté na hostiteli DB spusťte
mysqldump $OPTS | nc myhost.mydomain.com 7878
Tím se omezí hádky pro disková vřetena na hlavním serveru, aby zapisovaly výpis na disk, což mírně zrychluje váš výpis (za předpokladu, že síť je dostatečně rychlá, aby udržela krok, celkem bezpečný předpoklad pro dva hostitele ve stejném datovém centru). Navíc, pokud vytváříte novou podřízenou jednotku, ušetříte tím krok nutnosti přenášet soubor výpisu po jeho dokončení.
Upozornění – samozřejmě musíte mít dostatečnou šířku pásma sítě, abyste věci nesnesitelně nezpomalili, a pokud se relace TCP přeruší, musíte začít znovu, ale u většiny výpisů to není hlavní problém.
Nakonec bych chtěl objasnit jeden společný zmatek.
Navzdory tomu, jak často tyto příznaky vidíte v příkladech a výukových programech mysqldump, jsou zbytečné, protože jsou ve výchozím nastavení zapnuty:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Z http://dev.mysql.com/doc/refman/ 5.1/cs/mysqldump.html :
Z těchto chování je „--quick“ jedním z nejdůležitějších (přeskakuje ukládání celé sady výsledků do mezipaměti v mysqld před přenosem prvního řádku) a může být s „mysql“ (které ve výchozím nastavení NEZAPÍNÁ --quick) k dramatickému urychlení dotazů, které vracejí velkou sadu výsledků (např. výpis všech řádků velké tabulky).