SNABB dumpning av en tyst databas:
Att använda alternativet "-T " med mysqldump resulterar i massor av .sql- och .txt-filer i den angivna katalogen. Detta är ~50 % snabbare för att dumpa stora tabeller än en enskild .sql-fil med INSERT-satser (tar 1/3 mindre väggklockatid).
Dessutom finns det en stor fördel vid återställning om du kan ladda flera tabeller parallellt och mätta flera kärnor. På en 8-kärnig låda kan detta vara så mycket som en 8X skillnad i väggklockans tid för att återställa soptippen, utöver effektivitetsförbättringarna som tillhandahålls av "-T". Eftersom "-T" gör att varje tabell lagras i en separat fil, är det lättare att ladda dem parallellt än att dela isär en massiv .sql-fil.
Om man tar strategierna ovan till sin logiska ytterlighet kan man skapa ett skript för att dumpa en databas brett parallellt. Tja, det är precis vad Maakit mk-parallel-dump (se http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) och mk-parallel-restore verktyg är; perl-skript som gör flera anrop till det underliggande mysqldump-programmet. Men när jag försökte använda dessa hade jag problem med att få återställningen att slutföras utan dubbletter av nyckelfel som inte inträffade med vaniljdumpar, så kom ihåg att din körsträcka kan variera.
Dumpa data från en LIVE-databas (utan tjänstavbrott):
--single-transaction switchen är mycket användbar för att ta en dumpning av en livedatabas utan att behöva tysta den eller ta en dumpning av en slavdatabas utan att behöva sluta slaving.
Tyvärr är -T inte kompatibel med --single-transaction, så du får bara en.
Vanligtvis går det mycket snabbare att ta dumpningen än att återställa det. Det finns fortfarande utrymme för ett verktyg som tar den inkommande monolitiska dumpfilen och delar upp den i flera delar för att laddas parallellt. Såvitt jag vet finns ett sådant verktyg ännu inte.
Att överföra dumpen över nätverket är vanligtvis en vinst
För att lyssna efter en inkommande dump på en värdkörning:
nc -l 7878 > mysql-dump.sql
Kör sedan
på din DB-värdmysqldump $OPTS | nc myhost.mydomain.com 7878
Detta minskar konflikten för diskspindlarna på mastern från att skriva dumpen till disken och påskynda din dump något (förutsatt att nätverket är tillräckligt snabbt för att hänga med, ett ganska säkert antagande för två värdar i samma datacenter). Plus, om du bygger ut en ny slav, sparar detta steget att behöva överföra dumpfilen efter att den är klar.
Varningar – uppenbarligen måste du ha tillräckligt med nätverksbandbredd för att inte sakta ner saker olidligt, och om TCP-sessionen avbryts måste du börja om från början, men för de flesta dumpningar är detta inget större problem.
Till sist vill jag reda ut en vanlig förvirring.
Trots hur ofta du ser dessa flaggor i mysqldump-exempel och tutorials är de överflödiga eftersom de är PÅ som standard:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Från http://dev.mysql.com/doc/refman/ 5.1/en/mysqldump.html :
Av dessa beteenden är "--quick" ett av de viktigaste (hoppar över cacheläggning av hela resultatet i mysqld innan den första raden sänds), och kan vara med "mysql" (som INTE slår på --quick som standard) för att dramatiskt påskynda frågor som returnerar en stor resultatuppsättning (t.ex. dumpning av alla rader i en stor tabell).