Provedení výpisu a obnovení popsaným způsobem bude znamenat, že MySQL bude muset při importu dat kompletně znovu vytvořit indexy. Také musí pokaždé analyzovat data.
Bylo by mnohem efektivnější, kdybyste mohli kopírovat datové soubory ve formátu, kterému MySQL již rozumí. Dobrým způsobem, jak toho dosáhnout, je použít innobackupex od Percona
(Otevřený zdroj a distribuován jako součást XtraBackup ke stažení zde).
Tím se pořídí snímek tabulek MyISAM a pro tabulky InnoDB se zkopírují podkladové soubory a poté se proti nim přehraje protokol transakcí, aby byl zajištěn konzistentní stav. Může to udělat z živého serveru bez výpadků (nemám ponětí, jestli je to váš požadavek?)
Doporučuji, abyste si přečetli dokumentaci, ale pro vytvoření zálohy v její nejjednodušší formě použijte:
$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
$ innobackupex --apply-log /path/to/BACKUP-DIR/
Pokud jsou data na stejném počítači, pak má innobackupex dokonce jednoduchý příkaz pro obnovu:
$ innobackupex --copy-back /path/to/BACKUP-DIR
Existuje mnoho dalších možností a různých způsobů, jak skutečně zálohovat, takže bych vám opravdu doporučil, abyste si před zahájením dobře pročetli dokumentaci.
Pokud jde o rychlost, náš pomalý testovací server, který dělá přibližně 600 IOPS, dokáže pomocí této metody obnovit zálohu o velikosti 500 GB za přibližně 4 hodiny.
Na závěr:Zmínil jste, co by se dalo udělat pro urychlení importu. Většinou bude záležet na tom, jaké je hrdlo láhve. Operace importu jsou obvykle vázány na vstup/výstup (můžete to otestovat kontrolou čekání na io) a způsob, jak to urychlit, je rychlejší propustnost disku – buď rychlejší disky samotné, nebo více najednou.
Nezapomeňte zvýšit svůj „max_allowed_packet "" na dostatečně velkou velikost. To opravdu pomůže, pokud máte hodně textových dat. Použití vysoce výkonného hardwaru jistě zvýší rychlost importu dat.
mysql --max_allowed_packet=256M -u root -p < "database-file.sql"
Jedna věc, kterou můžete udělat, je
SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS=0
A také si můžete pohrát s hodnotami
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_flush_method
v my.cnf abyste mohli začít, ale obecně byste se měli podívat i na zbytek parametrů innodb, abyste zjistili, co vám nejlépe vyhovuje.
Toto je problém, který jsem měl v minulosti a nemám pocit, že jsem ho úplně vyřešil, ale doufám, že jsem se tímto směrem od začátku ukázal. Ušetřil bych si docela dost času.
Existuje mnoho parametrů, které chybí, abychom plně pochopili důvod problému. jako například:
- Verze MySQL
- Typ a rychlost disku
- Uvolněte paměť na serveru před spuštěním serveru MySQL
- výstup iostatu před a v době mysqldump.
- Jaké jsou parametry, které používáte k vytvoření souboru výpisu?
a mnoho dalších.
Pokusím se tedy uhodnout, že váš problém je v discích, protože mám 150 instancí MySQL, které spravuji s 3TB dat na jednom z nich, a obvykle je problémem disk
Nyní k řešení:
Za prvé – vaše MySQL není nakonfigurováno pro nejlepší výkon.
O nejdůležitějších nastaveních, která je třeba nakonfigurovat, si můžete přečíst v příspěvku na blogu Percona:http://www.percona.com/blog/2014/01/28/10-mysql-settings-to-tune-after-installation/
Zejména zkontrolujte parametry:
innodb_buffer_pool_size
innodb_flush_log_at_trx_commit
innodb_flush_method
Pokud je vaším problémem disk – čtení souboru ze stejné jednotky – problém ještě zhoršuje.
A pokud se váš server MySQL začne swapovat, protože nemá k dispozici dostatek paměti RAM – váš problém se ještě zvětší.
Chcete-li to zjistit, musíte na svém počítači před a v době obnovy spustit diagnostiku.
Kromě toho vám mohu doporučit, abyste k provedení úlohy přestavby použili jinou techniku, která funguje rychleji než mysqldump.
Je to Percona Xtrabackup - http://www.percona.com/doc/percona-xtrabackup/2.2/
Budete muset vytvořit zálohu s ním a obnovit z něj, nebo znovu vytvořit ze spuštěného serveru přímo s možností streamování.
Také verze MySQL od 5.5 - InnoDB funguje rychleji než MyISAM. Zvažte, zda byste na něj nezaměnili všechny své tabulky.