БЪРЗО изхвърляне на спряна база данни:
Използването на опцията "-T" с mysqldump води до много .sql и .txt файлове в посочената директория. Това е с ~50% по-бързо за изхвърляне на големи таблици, отколкото единичен .sql файл с оператори INSERT (отнема 1/3 по-малко време на стенен часовник).
Освен това има огромна полза при възстановяване, ако можете да заредите няколко таблици паралелно и да наситите множество ядра. При 8-ядрена кутия това може да бъде колкото 8X разлика във времето на стенен часовник за възстановяване на дъмп, в допълнение към подобренията на ефективността, предоставени от "-T". Тъй като "-T" кара всяка таблица да се съхранява в отделен файл, паралелното им зареждане е по-лесно, отколкото разделянето на масивен .sql файл.
Довеждайки стратегиите по-горе до тяхната логическа крайност, може да се създаде скрипт за паралелно изхвърляне на база данни широко. Е, точно това е Maakit mk-parallel-dump (вижте http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) и mk-parallel-restore инструментите са; perl скриптове, които правят множество извиквания към основната програма mysqldump. Въпреки това, когато се опитах да ги използвам, имах проблеми с завършването на възстановяването без дублиращи се ключови грешки, които не са се случили при изхвърлянето на ванилия, така че имайте предвид, че вашият пробег може да варира.
Изхвърляне на данни от база данни НА ЖИВО (без прекъсване на услугата):
Превключвателят --single-transaction е много полезен за вземане на дъмп на жива база данни, без да се налага да я спирате или вземане на дъмп на подчинена база данни, без да се налага да спирате подчинението.
За съжаление -T не е съвместим с --single-transaction, така че получавате само една.
Обикновено вземането на сметището е много по-бързо от възстановяването му. Все още има място за инструмент, който взема входящия монолитен дъмп файл и го разбива на множество части, за да бъде зареден паралелно. Доколкото ми е известно, такъв инструмент все още не съществува.
Прехвърлянето на дъмп през мрежата обикновено е печеливша
За да слушате за входящ дъмп при изпълнение на един хост:
nc -l 7878 > mysql-dump.sql
След това на вашия DB хост стартирайте
mysqldump $OPTS | nc myhost.mydomain.com 7878
Това намалява конкуренцията за дисковите шпиндели на главния компютър от записване на дъмпа на диск, като леко ускорява вашия дъмп (ако приемем, че мрежата е достатъчно бърза, за да се поддържа, доста безопасно предположение за два хоста в един и същ център за данни). Освен това, ако създавате нов подчинен, това спестява стъпката от необходимостта да прехвърлите дъмп файла, след като приключи.
Предупреждения – очевидно трябва да имате достатъчно мрежова честотна лента, за да не забавяте нещата непоносимо, и ако TCP сесията се счупи, трябва да започнете отначало, но за повечето изхвърляния това не е основен проблем.
И накрая, искам да изясня един момент на често срещано объркване.
Въпреки колко често виждате тези флагове в примери и уроци на mysqldump, те са излишни, защото са включени по подразбиране:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
От http://dev.mysql.com/doc/refman/ 5.1/en/mysqldump.html :
От тези поведения "--quick" е едно от най-важните (пропуска кеширането на целия набор от резултати в mysqld преди предаване на първия ред) и може да бъде с "mysql" (което НЕ включва --quick по подразбиране) за драстично ускоряване на заявки, които връщат голям набор от резултати (напр. изхвърляне на всички редове на голяма таблица).
